Remove Ex-Mode from Neovim(github.com) |
Remove Ex-Mode from Neovim(github.com) |
Yes, there will be controversies. There always are. But even collaborative open source projects need strong-willed leadership, or they cannot grow properly.
nnoremap Q <nop>
So they have a mode you enter when pressing q (which quits many other programs) that you can't leave if you don't know the leave command?
This is comedy gold. :D
Vim to me is like having a smooth technical conversation with a work partner. Emacs is like conversing with my partially deaf grandpa.
Actually, when entering Ex mode you get a little helpful message that says Type "visual" to go to Normal mode.
If you do press "q" though, you're in macro mode, and you don't get any helpful message that tells you that you have to press "q" another time to exit it.
Hah, for many that is Vim itself!
If it's going to become more of a radical departure from Vim and start omitting features as well as adding, I would rather they change the name of the project instead, one that alludes to its Vim heritage rather than having a prefix that means 'new'. Is it a new version of Vim? Or an editor that started as a fork of Vim, but only has the good parts?
Edit: Removed my insult of the name 'Neovim'. Just going to state that I dislike it.
I hope eventually the community will just use the 'nvim' abbreviation to refer to Neovim, just like 'vim' is 'vi improved' abbreviated
It's alright. You're doing a great job though, regardless. I really can't wait till it's done!
> I hope eventually the community will just use the 'nvim'
Is there a chance the project might choose a different name? If not, nvim isn't so bad. It could be better, though. A good name is important.
https://github.com/neovim/neovim/issues/272#issuecomment-370...
So even if you have neovim set up as your "vi", you'll probably still have an "ex" available on your command line. It'll just be symlinked to legacy vim, not neovim.
I, personally, used ex-mode only a couple of times, so even if I will use neovim I don't think I would care. But that just doesn't sound like a right think to do.
https://github.com/neovim/neovim/issues/1089#issuecomment-56...
You just can't switch between ex and vi modes.
Edited to add:
FTA:
"As for the ex command-line utility, that can easily be implemented as separate program that talks to nvim via msgpack-rpc"
Great! I have no to minimal objection.
Will a similar conversation happen with Replace mode? I use this mode less than Ex mode and it has a useful key bind (R) that could be recycled.
Can anyone sell me on this project? I looked at the homepage and README, but they're both pretty hand-wavey.
What problems does nvim solve for experienced vim users?
Also it's good to make this kind of feature as plugin, so it will reduce the code complexity.
I've never used ex mode, so I could be wrong about this, but briefly reading through the description for it made it seem like you could replicate the functionality through the neovim plugin/messaging architecture, and probably get something cleaner on the other side.
(I've gone and elaborated on my own comment. I might have misworded my intent.)
A huge part of good design is being able to make good (and often hard) decisions about when and where to simplify. This includes things like occasionally eliminating features. Ones that have shipped. For months, or even decades.
There are very solid arguments presented in that thread for interactive Ex-mode's removal. Specifically, one problem that @tarruda mentions is that ex-mode is one of the blockers for "implementing GUIs over msgpack API." Seriously, I'd trade ex-mode for that in a heartbeat!
[1] http://vimdoc.sourceforge.net/htmldoc/intro.html#Ex-mode
Personally I don't use vim, even though I like the concept of vim, because it simply doesn't fit with the ecosystem I want to use (it seems to be hard to integrate clang for auto-complete and syntax highlighting into vim for example, without long hangs or strange visual effects for example, because vim doesn't support threading for example)
I get a shiver every time I hear they are parting from the Vim way, but so far, I have to say their decisions seem very wise.
So he shouldn't remove it because of some strongly held principle of a random person on the internet? Even though that person in practice doesn't have any problem with it? That sounds backwards.
That gives you a buffer you can look through previous commands and use normal-mode commands to edit them.
Also, you don't need Ex mode to edit last commands. You can just press Up from cmdline.
I really did start using Emacs when I started learning Clojure(/Script), though, and made it my main language and platform investment. And org-mode had been playing a part in my want of switching for a while, building up for years. I also told myself it'd be better to hack in a lisp but Elisp is so fucked up I still haven't mustered up the courage to properly learn all its old and unexpressive idiosyncracies (god, even creating a closure requires explicit verbosity!) Meanwhile I don't think I can bear VimScript anymore--since getting into Clojure my language standards have gone considerably up. As a result I do the odd hack but haven't developed more powerful plugins in a while, not in elisp nor vimscript; I'm in a psychological limbo there. Kinda hoping Guile-Emacs takes off so I can do stuff in scheme.
Out of curiosity, what do you mean by 'verbosity' in this case? I just Googled and it looks like Elisp uses the same (lambda (arg) form) syntax, like CL---is this what you're referring to?
Obviously, whether this makes sense depends on what the something is - if it's some GUI flourish, then it's irrelevant either way, but a GUI flourish is not going to be why I move to neovim in the first place.
This seems like a reasonable separation of concerns.
http://www.emacswiki.org/emacs/LexicalBinding
...for some of the issues.
This way, I can skip the awkward @q step, and keep hitting Q instead of @@ to re-run the macro.
it only took about a week to retrain myself for it.
here's the command... put it at the top of your vimrc before anything else so it works with your plugins.
let mapleader=" "
Prefixing 'new' to the name of the forked project is as lazy as it can get [1]. 'Neo' is one step from that.
Vim itself wouldn't be a good name if it was just meaning "Vi iMproved", but 'Vim' is also a dictionary word meaning "energy; enthusiasm". A positive dictionary word, and a pseudo-acronym. That works well.
The dictionary has many words that start with Vi, or have it as a substring: http://www.scrabblefinder.com/starts-with/vi/
While just using a dictionary word may be a bit lazy, it is the allusion I was referring to in my previous comment. It would be an allusion to Vim also being a dictionary word, chosen because it starts with 'vi'. The cycle of improvement would continue.
For example, 'Vigor' would be a decent name, as "Vim and Vigor"[2] are a common phrase.
Definitely not saying that should be the name, but it's a path to try and see what the community might like.
[1]: The laziest is Nintendo's "New 3DS": http://en.wikipedia.org/wiki/New_Nintendo_3DS [2]: http://dictionary.reference.com/browse/vim+and+vigor
But I like your idea. Something like Vittle as a whittled-down version of vim.
I actually hope that Neovim is temporary and Bram can gracefully accept the Neovim code as the official Vim once Neovim is stable. And Vim can become "Legacy Vim", supporting modes and OSs Neovim doesn't support anymore. Vim itself does the same thing - it has downloads for older versions in order to support MS DOS, for example (I'm not 100% sure about this - the www.vim.org page gives me a "Connection reset" right now - but I remember it doing this).
Me too. I would rather it become an actual 'new' Vim.
Vim always seems like magic to me. I always use nano/pico when I need to edit something in the command line.
I like my shells to have white backgrounds. I don't know why, but it's just restful to my eyes. Nano's default syntax highlighting on bash scripts is to highlight strings in bright yellow, which on a black backdrop makes sense, but on white is impossible to read.
It took years of working with shell scripts, and a familiar litany of "I'll just look up how to change this... [one hour later] I have no idea, let's just change my Konsole background to black for a little while..." before one day I was like, "Dammit, I just need to change this one little thing over here" and typed vi instead, thinking that it was so simple that surely it'd have no highlighting.
But it did have highlighting, and it was highlighting which wasn't bonkers like nano's was.
I had struggled with vi a lot before. I did not like it. Still don't. The thing is, they could probably have won me over a million years earlier by starting me off at insert mode on the first line! It is modal, and I don't even like the modality of my cruise control system on my car, let alone the modal nature of vi -- but at least a text editor should dump a beginner in the mode which, y'know, edits text. I'm only just getting used to hjkl keys, and only then because of nethack. I don't know enough to make super expert use of vim.
But, all that aside, it won because it didn't force me to squint at yellow-on-white text every time I was SSH'ed into a system which needed me to edit string-laden syntax-highlighted files.
I wouldn't like "open in insert mode" at all - if I'm opening an existing file, I probably want to edit it, not just add text (especially not at the beginning) - which means the first thing I'm probably wanting to do is navigate, which is much easier done in command mode.
When opening a new file, there's a better argument for starting in insert mode, but even then I'm likely to want to populate the buffer with the output of some command.
Of course, hitting escape first isn't disastrous - but neither is hitting i before you type.
All of that said, my defaults don't need to be your defaults! Add startinsert to your vimrc to get the behavior you want:
echo startinsert >>~/.vimrcUsed nano just for some small changes when using SSH.
If my only use were editing files in CLI, though, I'd have always used nano and not learned vim, as well.
Yes, but, it tried to be with the 'compatible' option: http://vimdoc.sourceforge.net/htmldoc/options.html#'compatib... (Not to say it fully succeeded.)
> And your reasoning lacks a logical basis, with all points being subjective.
If by points you mean my list at the top, those are facts. Past the list, everything else is subjective, yes. Liking and disliking a name is a subjective matter. Whether a name is 'appropriate' is very subjective. Should I have made a disclaimer that it was my opinion?
I'm just observing that I would have understood it much more rapidly if I'd started in insert mode my first few times, because then the expressive command mode enabled by the Esc key seems "layered onto" the basic insert-mode editing that a new user expects to be the main purpose of a text editor. From insert mode, you can page down and delete and insert pretty straightforwardly; and you get gently introduced to command-mode when you say "hey, how do I save this document now?". So pedagogically it would have really helped.
I just realized I only use my left thumb with the spacebar, so the ambidextrous argument doesn't fly for me.
But I did realize space currently does nothing for me in normal mode. So I made it work like less/more, i.e., it pages the screen down:
nnoremap <space> <C-d> nnoremap <S-space> <C-u>
nnoremap <space> <C-d>
The shift-space doesn't work.