Hacker News new | past | comments | ask | show | jobs | submit login

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




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.


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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: