Remove Ex-Mode from Neovim | Hacker News Reader

Remove Ex-Mode from Neovim

github.com

176 pointsstepanbujnak119 comments

This is one of the reasons I very strongly support the Neovim project. They are taking an incredibly sensible and pragmatic approach to modernizing Vim.

Yes, there will be controversies. There always are. But even collaborative open source projects need strong-willed leadership, or they cannot grow properly.

For those who, like me, had never heard of Ex-mode: https://en.wikibooks.org/wiki/Learning_the_vi_Editor/Vim/Mod...

aka "Oh, that's the key I have been hitting by accident"

Yea, I finally got fed up one day and put

  nnoremap Q <nop>

in my .vimrc. No more "how did I get HERE?"

oh man, thank you very much!

No problem :)

I usually record my throwaway macros to q (because hitting qq is so easy), so I've bound Q to 'call the most recently defined macro'. I would post something to put in your .vimrc, but I use the vim emulator evil-mode in Emacs.

This way, I can skip the awkward @q step, and keep hitting Q instead of @@ to re-run the macro.

that is a great idea!

I use <space> for this. It's very gratifying, mashing the spacebar to repeat a macro.

using space for the leader is one thing that I absolutely love... I was using , for it but space is so much easier and nicer to use. you are not limited to one finger to start the leader command so it makes both sides of the keyboard nice to use for leader chords.

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=" "

Hm, this is actually a really neat idea. I'm going to try this!

It was painful for a few days but after that I can't imagine going back to , especially since that is actually a useful default binding.

I have mapleader set to ",", which has served me well.

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>

Should just be:

nnoremap <space> <C-d>

The shift-space doesn't work.

even if you only use your left thumb to hit space it's still faster than using , for your leader as the thumb really only hits the space key, command(if you are on a mac)/alt(windows) and maybe option/alt if you are on a mac. and it's natural to use the left keys after hitting space. whereas using any key on the right side of the keyboard after a leader press is awkward and slower because the , key is pressed with your middle finger. it's also a smaller target so it's harder to hit.

See space.vim for another cool use for the spacebar. https://github.com/spiiph/vim-space

How do you call the most recently defined macro? I just have Q bound to @q, but if I could make it more general that would be awesome.

@@ re-runs the last macro.

This is wonderful, I must do this, I keep hitting `q` instead of `:q` when I want to quit Vim, and it's a pain to get out of...

And for those who are still stuck in it ... :vi to end the madness

exit also works.

The instructions tell me to type "visual" and that seems to work.

"... similar to the command line mode ... Unlike the command-line mode you won't return to normal mode automatically ... enter ... by typing a Q in normal mode"

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

It was in fact the original mode. vi was the visual mode for ex.

Not "q", but "Q".

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.

I see, thanks for the clarification :)

Vim always seems like magic to me. I always use nano/pico when I need to edit something in the command line.

Yeah, I remember when I was first learning Linux, I was pretty much thrown into the deep end with nobody to help me much. I got into vim to edit a text file, and was... completely lost at sea. I figured out how to install nano and have never touched another Linux text editor since.

Vim is a programmer's dream.

If my only use were editing files in CLI, though, I'd have always used nano and not learned vim, as well.

vi is a sysadmin's dream. I use it for editing any and all files on myriad remote machines. I especially love the ! command which lets me pipe parts of a buffer through shell commands such as column.

I thought IDEs were a programmer's dream :D

IDEs are a programmer's depressing reality.

It seems like "perform a bunch of pretty similar changes across most lines of a file with a couple hundred lines" is the kind of thing that shows up far more regularly for sysadmins than for programmers, and it's something where vim shines. The last time I worked somewhere with someone in an explicit "sysadmin" role, they were regularly bugging me for vim tips (not that I minded).

I'll tell you the dinky stupid reason why I started using vim over nano:

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 always used IDEs when I wanted highlighting.

Used nano just for some small changes when using SSH.

"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!"

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 >>~/.vimrc

Very interesting! I'm more interested in it as an attraction to new users; I agree that "morally" it should probably start in command mode since it should be designed for its most common use cases first.

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 have mixed feelings on the pedagogy. On the one hand, it would have eliminated some frustration, which would have presumably been helpful. On the other, driving home that "normal mode is normal" serves a pedagogical purpose as well. The power of vim really starts to emerge when you internalize that inserting text is just another action.

"evim" (easy Vim) is normally installed wherever vim is, and opens in insert mode by default.

To be clear, it's q at the : prompt to quit vim, whether in visual mode or ex mode. It's Q in normal mode to enter ex mode (or you can start that way with -E).

>you can't leave if you don't know the leave command?

Hah, for many that is Vim itself!

As much as vim is known as the modal editor, that sounds like you're describing Emacs (I'm using evil-mode instead of vim these days.) Whereas vim has dual-modality as its core, it's very well-defined and self-contained as far as modes go, and with the exception of this Ex mode, you can get out of any weird state by pressing Esc. Emacs, on the other hand, has potentially dozens of different 'modes' you can accidentally find yourself in, and each one seeming to have a different way of getting out, it drives me insane! Even a question in Emacs which can only be answered by typing out 'yes' or 'no', and by no other frigging escape sequence, is a mode come from hell. Worse yet, press Esc and Emacs goes into the mode of a mode where it briefly becomes unresponsive as it lets you know that you are WRONG.

Vim to me is like having a smooth technical conversation with a work partner. Emacs is like conversing with my partially deaf grandpa.

I'm interested to hear why you're using evil-mode instead of vim if that's how you feel. I'm using vim with slimv for Lisp hacking at the moment and I have to admit that there are some whoopsies, but not enough to make me learn to use a whole new editor :)

Well, rant and occasional surprise aside, I've found evil-mode to truly be a better implementation of vi than vim itself, at least where it concerns me (as formerly a pretty advanced vim user and plugin developer, it took me some adapting to stop using all the ex vim idioms and the like.) It's faster to handle big files and execute macros, overall snappier and has a profoundly better %s///g with real time preview.

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.

Thanks for the insight, much appreciated.

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?

Lexical binding is a "new" feature for elisp. See:

http://www.emacswiki.org/emacs/LexicalBinding

...for some of the issues.

Would you say that emacs (with evil-mode) is significantly better than vim using ScreenShell or slimv, for clojure development?

I really didn't try Clojure on Vim, at the time Emacs seemed unambiguously like the authoritative option and it did serve as an excuse for me to jump into Emacs. For Clojure though, I find that Paredit tremendously reduces my need of vim motions. But evil-mode is great for all my prose editing needs (along with org-mode) and I do find it more robust than Vim at all the fundamental vi functionality.

I tried using evil and it just messed up my brain too much. I learned emacs and vim properly and their methods of operation are now ingrained in my muscle memory, entirely separate from one another. To go back now would be like asking someone to use a mouse and keyboard to drive their car.

C-g almost always helps.

This is like dropping support for Internet Explorer 6 in a website - code gets cleaner at the expense of a minor group of users getting a worse experience. I think it is a good tradeoff.

More like IE3. Nobody uses ex mode.

It's not true. Some still uses it extensively in the case of editing the last commands. But there is alternative way.

I am happy that they will remove this mode in the future :)

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.

Good riddance. It's cruft. I've used it exactly twice, and never was it something I couldn't have done on the command line. It might be useful on Windows, I'm not sure? But if you're on a *nix, there really isn't any point.

While I don't particularly care for ex-mode, I think it's weird to be calling it Neo 'vim' without it.

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.

Throw the baby out with the bath water much?

Elaborate, please.

(I've gone and elaborated on my own comment. I might have misworded my intent.)

Bram hasn't complained about their usage of the name (unlike the Standard Markdown fiasco). And as a Vim user what they're doing seems what Vim always wanted to do before Bram was sidetracked by other projects: they're making Vi Improved. A lot of the changes they're making seem to be redoing the Vim internals using 21st century software development practices (continuous integration: builds, tests, linting, refactoring, removing deprecated bits, etc).

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).

> I actually hope that Neovim is temporary and Bram can gracefully accept the Neovim code as the official Vim once Neovim is stable.

Me too. I would rather it become an actual 'new' Vim.

You want to change the name from neovim because they want to remove functionality that I'm guessing maybe 1% of the users use regularly. Even though for 99%, neovim is vim only modernized and cleaned up. It's illogical as you're doing a disservice to the users, and neovim is a clear name that describes what it is. New vim.

- It is a fork of Vim. - It is omitting some features. - It is adding a number of high level features. - It will not be fully backwards compatible.

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

Vim wasn't backwards compatible with vi. And your reasoning lacks a logical basis, with all points being subjective.

> Vim wasn't backwards compatible with vi.

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?

Um, no, they aren't facts at all.

Vigor already exists as a cruel parody of vi: https://en.wikipedia.org/wiki/Vigor_(software)

But I like your idea. Something like Vittle as a whittled-down version of vim.

My understanding of "Ex" is that it is a standalone program that happens to be implemented within Vim, which I think is a bit of an oddity. A radical departure for Neovim to take would be to change the key bindings or go to modeless operation.

The name is temporary, and discussion about the name has been temporarily halted because there are more important concerns.

https://github.com/neovim/neovim/issues/272#issuecomment-370...

Thank you. This is good news.

I'm the project founder and also dislike it. I admit it was one of the first things that came to my head(The name was inspired by some of @Shougo plugins). If I knew the project would get so popular, I would have put more thought into it. Too late now :(

I hope eventually the community will just use the 'nvim' abbreviation to refer to Neovim, just like 'vim' is 'vi improved' abbreviated

> If I knew the project would get so popular, I would have put more thought into it.

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.

Considering that there's already an "nvi", that might be confusing... but I agree, a name change may be warranted. (personally I like it)

http://en.wikipedia.org/wiki/Nvi

There isn't usually too much confusion, at least among users, about the different between vi and vim. Also, have never heard of nvi, whereas nvim seems like it's going places.

I've been using vim for 7 years and I've never even attempted to use this mode. Am I missing out?

It seems like a very good way of using vim knowledge to do non-interactive text processing. You could say, indent a javascript file that is ugly.

easier than hitting gg=G ?

non-interactive

Usually not, but over 7 years it's quite probable that there was a couple of times when it would be useful. It's good for batch processing (maybe over several files) using usual vim commands. Something like awk embedded in vim.

You might be, if you write plugins for vim! But if you don't, then no, probably not. It's handy to test some arbitrary commands which might go into a vim script or, more likely for the average user of vim, your .vimrc file.

As an old "vi" user, I used it quite a bit both while editing and to test ex scripts. To me, by removing it, they will compete with emacs and the likes but not with vi/vim.

Burrrrn!

AFAICT, ex-mode is usually used for scripting, as an alternative to sed, awk, and/or perl.

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.

The post doesn't make it clear at first, but they're not removing support for reading ex commands from stdin, just the interactive ex mode you can enter from inside the editor.

Removing pretty powerful feature just because author of fork doesn't use it sounds… well, actually author of fork can remove whatever he likes, but presenting neovim like "refactord vim with more features" isn't fair or even plausible in this case. And for what reasons? Oh, I see, it makes code complicated. Did he think vim'c codebase is scary for no reason? Removing all the code from vim would be the ultimate simplification in that case. It's not popular feature? Well, I believe that there can still be more vim users that don't use macros, maybe remove them as well? Or maybe just replace vim with nano?

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.

Personally, I think this is an excellent change. If neovim remains 100% compatible with vim, down to every minor issue, then it will be very hard to usefully improve.

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)

You may want to try https://github.com/Valloric/YouCompleteMe Does exactly what you describe wanting, and very well IMHO.

neocomplete.vim[1] and neocomplcache.vim[2] are nifty alternatives if you don't prefer YouCompleteMe.

[1]: https://github.com/Shougo/neocomplete.vim

[2]: https://github.com/Shougo/neocomplcache.vim

I'd like very much if Neovim adds functionality like YouCompleteMe out of the box. It's probably the most "complicated" in terms of dependencies, etc. VIM plugin that I have to install.

Comparing Ex mode to macros is disingenuous.

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.

The project aims to refactor vim's codebase to simplify development and allow new developers to join in by removing old, deprecated code. It doesn't say it is supposed to be 1:1 replacement only with newer code, and from what I've read on both their GitHub issues page and Hacker News, 99% of Vim users actually don't use Ex-mode. There is simply no point spending time and resources to keep in in the tree for the 1% of people actually using it. And even if ex-mode is something some people can't live without, there is still good ol' Vim.

Or they can fork neovim and start a neovim-with-exmode project!

> 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.

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.

If you like certain VIM features you can keep using VIM.

Until neovim actually does something cool and new that you want to use. Ex mode isn't something I need often, but it's fantastic on a sufficiently slow connection (of which there are fewer these days) or a sufficiently broken terminal (slightly more common), and when you need it you need it to work.

Why don't you just keep both installed?

When neovim does something new and cool that I want to use, then ex-mode-in-vim will obviously not support that new and cool something. If neovim continues to provide an ex mode, then it will be available to me.

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.

If you really like ex you can just use ex.

They're not removing command line mode, they're removing interactive Ex-mode[1]. Batch ex-mode from the command line (nvim -e) stays. From the research the team has done, most users 1) don't even know about it, 2) are annoyed when it is triggered by accident, and 3) when they do know about it, just remap it. And yes, there are a few users of ex-mode out there.

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

Sorry meant to up vote but hit the down arrow. Hope someone else compensates for my mistake and I'll delete this comment.

I don't know that there is any good reason to allow a move from visual mode to ex mode (or vice-versa). I do think that ex mode is very important - though I would expect you could implement it as its own UI over msgpack?

As neovim matures I think the opportunities for rich extension and scripting are going to blow away anything vi/vim users have ever had. I think ex-mode could be reimplemented as you suggest, or we'll end up with other awesome approaches that were simply unthinkable in the old architecture and codebase.

It looks like tarruda explicitly says, "As for the ex command-line utility, that can easily be implemented as separate program that talks to nvim via msgpack-rpc".

This seems like a reasonable separation of concerns.

Ugh. Some awful distributions remove ed(1) by default, when that happens, I use vi's ex mode as a substitute. Now these people want to remove that too, amazing. I can only hope this vim fork never becomes the default vi on any systems I am forced to use...

Nah, they're keeping that:

https://github.com/neovim/neovim/issues/1089#issuecomment-56...

You just can't switch between ex and vi modes.

Can they implement ex over the same msgpack interface they want for GUIs? The ability to switch back and forth between ex mode and visual mode is much lower priority than the ability to interface with my editor over something resembling ex (which itself is not super high priority, but this definitely falls in the "cons" column for neovim).

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.

I have been using Ex mode for it's REPL like qualities while learning vimscript, it's a useful feature if you are writing vim plugins or doing complex search/replace operations.

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.

I doubt it. Apart from the fact that at least I find replace mode useful, I think their main reason is not just because most people don't use it, but also because ex mode behaves inconsistently.

But uh, with the python, ruby, golang, lua (or whatever else has been chosen) integration do you really need vimscript any more?

Although I have no idea how good or bad this will turn out, I think it's a very good idea to kill edge features and instead focus on treating edge cases of core features better.

Hadn't heard of nvim until today.

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?

Search Neovim in the Hacker news search, there was a lengthy discussion less then a year ago here.

It is trying to refactor Vim and update it. If those sources are all too "hand-wavey", here's the consolidated feed for the development in the last months: http://neovim.org/news/archive/

I probably feel the same way about this mode as my mom feels in a terminal window.

as a developer, I think it's good to remove some rare feature to reduce code complexity.

Also it's good to make this kind of feature as plugin, so it will reduce the code complexity.

I was thinking something along these lines.

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 accidentally pushed the wrong button

Very well.

Removing "NeoVim" from the title removed the context as well. As it is, the title doesn't make any sense.

We put it back. The real problem here is that "neovim" doesn't show in the domain, which is part of the title row. "github.com" is far too generic to be meaningful. We may experiment with making the domain say, e.g., "github.com/neovim" for github.com and one or two other popular sites.

That would definitely help.

Reply on news.ycombinator.com