Remove Ex-Mode #1089

Closed
atwupack opened this Issue Aug 19, 2014 · 75 comments

Projects

None yet
@atwupack
Contributor

In PR #1049 @tarruda made the suggestion to remove Ex-mode from Neovim. This issue is the place to discuss that suggestion (instead of the PR).


Want to back this issue? Place a bounty on it! We accept bounties via Bountysource.

@ZyX-I
Contributor
ZyX-I commented Aug 19, 2014

Copying my messages here:

Ex mode would be useful if it did not have the following problems:

  1. Screen is not updated after your actions.
  2. History is not accessible.
  3. Mappings and abbreviations are disabled.
  4. This mode cannot be quit with <C-c> or <Esc> which is inconsistent with any other mode I can think of.

gQ is only slightly better because it takes out 2. and 3. In the current state Ex mode is close to useless… when trying to use it manually. There are advantages in using it from mappings:

  1. You do not have to type : each time.

  2. You do not have to use <C-u> to drop possible count.

  3. It acts effectively as <silent> modifier, but is two characters shorter (<CR>vi in place of <silent> (leading Q substitutes :, trailing <CR> is required in any case)) and only silences commands run in that mode.

  4. When using a sequence of commands you cannot join with | (e.g. any command after normal) you still have a consistent way of separating them without using :execute: just always use <CR> to separate commands.

  5. When executing command from external source using :execute to execute string like "try\nnormal! abc\ncatch\nechomsg v:exception\nendtry" you will not get weird results like catch… appearing in your buffer (:normal swallows catch and the rest of the string): one may use execute 'normal Q'."try\nnormal abc\ncatch\nechomsg v:exception\nendtry"."\nvi\n" (note though about silencing: echomsg will only put v:exception in messages in my example, not display it for user).

  6. Even <silent> modifier will not help you in case

    set more  " With `nomore` you still get “Press ENTER…”.
    nnoremap <silent> QT :for x in range(100)\|echo x\|endfor<CR>
    

    . Q will:

    nnoremap QT Qfor x in range(100)\|echo x\|endfor<CR>vi<CR>
    

    . :silent command also will do to be honest.

  7. And as mentioned earlier you may use Ex mode for scripting Vim without losing the ability to escape and do something in normal mode if needed.

Note that none of these features are disabled by mapping Q to <Nop> since there are nore variants of mappings. Also note that I had not actually ever use this feature, just needed to ask myself “assuming I am using this feature why am I doing this?” Actual users may find more points in defence.

@tarruda
Member
tarruda commented Aug 19, 2014

Some other reasons for doing this:

  • It's not an useful/popular feature
  • It makes the code more complex (another mode) to handle keys
  • It doesn't use use screen.c for redrawing and storing screen state

The third point is the most important because we need to separate redraw notifications from presentation logic to become possible implementing GUIs over msgpack API. Work on this has started on #781 but it's still not complete because Neovim has code that prints directly to stdout/stderr(ex mode, command-line, messages, dialogs) as opposed to mutating screen state data structures and trigerring redraw code

I'd like to take this opportunity to propose another change: Replace command-line for a command window with special mappings that simulate the current command-line behavior(eg: <esc> for closing the window and <tab> for completions). This would be great because it would greatly simplify #781 while allowing the removal of thousands of SLOC and simplifying codebase. @ZyX-I what impacts can you see from such change? Is it a viable option?

@webdesserts

As a non-power-user of vim, I've always found that mode extremely annoying. Never use it and it makes me feel like a new vim user all over again when I accidentally hit it ("What are my keys doing? How do I exit this damn thing?"). I'm sure there are some more experienced vim user's that use it though.

@justinmk
Member

When using a sequence of commands you cannot join with | (e.g. any command after normal) you still have a consistent way of separating them without using :execute

This could be useful. But I think 99% of people will use :execute.

Even modifier will not help you in case
set more " With nomore you still get “Press ENTER…”.

This could be useful, but:

:silent command also will do to be honest.

Ex-mode is part of that "1% incompatibility" that we may need to exercise. If we remove it (1) we lose almost nothing, (2) we avoid a significant cost, and (3) we gain needed flexibility.

In fact I would say the removal of :shell would be more controversial than the removal of ex-mode.

Past discussions on r/vim/ indicate that this mode won't be missed:

update:

I created an r/vim/ post asking about Q. A person linked to a great article: see the "Semi-Automatic Substitutions" section of this: http://dahu.github.io/vim_waz_ere/4_substitute_command.html

@adelarsq

I think that the best way to do this would be provide a way to add and remove modes in Vim. So this and other modes can be added in the future, like a table mode. I do not use this mode, so I did a map to repeat macros instead (nmap Q @@).

@ZyX-I
Contributor
ZyX-I commented Aug 20, 2014

I think that this mode should be changed to use appropriate screen-manipulating functions and that’s all.

@adelarsq This was suggested as a part of #421.

@adelarsq

@ZyX-I Cool!

@matthiasbeyer
Contributor

IMHO, ex mode is one of the killer features of vim and removing it would be like ripping out the very heart of it.

From my understanding what @ZyX-I said, it would just require some polishing and attaching, not a rewrite or something like this. I would love to see this in neovim!

@mikaelj
mikaelj commented Sep 1, 2014

Do you really use "vim -e" often? I don't think I've ever heard about
anyone using it.

  • Micke

On Sat, Aug 30, 2014 at 1:03 AM, Matthias Beyer notifications@github.com
wrote:

IMHO, ex mode is one of the killer features of vim and removing it would
be like ripping out the very heart of it.

From my understanding what @ZyX-I https://github.com/ZyX-I said, it
would just require some polishing and attaching, not a rewrite or something
like this. I would love to see this in neovim!


Reply to this email directly or view it on GitHub
#1089 (comment).

@matthiasbeyer
Contributor

No, that feature not. But inside vim, I use ex mode! And I would bet there are a lot of people who wrote vim-ex-mode-scripts!

@Grimy
Contributor
Grimy commented Sep 1, 2014

I strongly agree. Ex-mode is near useless and can be extremely annoying when triggered accidentally.

@tarruda
Member
tarruda commented Sep 1, 2014

@matthiasbeyer, are saying that you use ex mode, the one which requires typing "visual" to go back rather than using the command line? That simply doesn't make sense

@matthiasbeyer
Contributor

@tarruda Sometimes, it makes sense to simplify some steps when editing files!

@ZyX-I
Contributor
ZyX-I commented Sep 1, 2014

On September 1, 2014 3:39:33 PM GMT+03:00, Thiago de Arruda notifications@github.com wrote:

@matthiasbeyer, are saying that you use ex mode, the one which requires
typing "visual" to go back rather than using the command line? That
simply doesn't make sense


Reply to this email directly or view it on GitHub:
#1089 (comment)

'vi' (not 'visual', short variants are here exactly for this purpose) is very fast to type for a touch typist.

@tarruda
Member
tarruda commented Sep 1, 2014

@mathiasbynens I'm sorry that you use ex mode, but it is going to be removed anyway. I stick with my previous arguments and also reply to @ZyX-I comment:

I think that this mode should be changed to use appropriate screen-manipulating functions and that’s all

No, that is not all. Keeping ex mode means this:

  • Increasing/modifying the already horrible code in screen.c to support ex mode
  • Continue to maintain 5k loc in ex_getln.c to support a legacy feature that almost no one uses and essentially does the same as command-line and command window
@mathiasbynens
Contributor

I think you meant @matthiasbeyer :)

@tarruda
Member
tarruda commented Sep 1, 2014

I think you meant @matthiasbeyer :)

👍 Sorry

@ewindisch

The 'ex' command utility is still useful. It's important to remember that ex is scriptable, and not just scriptable, but there are scripts built around it instead of tools such as sed/awk. It's also useful on less capable terminals, single-line displays, etc. I've used 'ex' on numerous occasions as a sysadmin when, for one reason or another, my terminal was not capable of properly rendering text, or when operating blind. Yes, sed is an alternative to ex, but it's not a drop-in one.

This isn't to say that Neovim should carry 'ex', but that 'ex' is useful and a working implementation should be maintained and supported somewhere. As many distributions currently link ex to vim by default, this change will presumably (and hopefully) trigger distributions to carry the BSD ex/vi, and/or improvements to busybox's ex.

@tarruda
Member
tarruda commented Sep 19, 2014

The 'ex' command utility is still useful. It's important to remember that ex is scriptable, and not just scriptable, but there are scripts built around it instead of tools such as sed/awk. It's also useful on less capable terminals, single-line displays, etc. I've used 'ex' on numerous occasions as a sysadmin when, for one reason or another, my terminal was not capable of properly rendering text, or when operating blind. Yes, sed is an alternative to ex, but it's not a drop-in one.

This isn't to say that Neovim should carry 'ex', but that 'ex' is useful and a working implementation should be maintained and supported somewhere. As many distributions currently link ex to vim by default, this change will presumably (and hopefully) trigger distributions to carry the BSD ex/vi, and/or improvements to busybox's ex.

Note that we still plan to support reading ex commands from standard input, so the main use case of ex mode which is command-line scripting isn't going to be affected. What will be removed is the interactive ex mode that can be entered from the editor.

As for the ex command-line utility, that can easily be implemented as separate program that talks to nvim via msgpack-rpc

@phmarek
phmarek commented Sep 19, 2014

I'm also using ex as a kind-of sed/awk/perl replacement sometimes.

For example, searching for some pattern, go to the ( in that line, and jumping to the (corresponding!) ) later on is not that easy with the other tools; you need at least some kind of recursive RE.

So, answering the comment that just came in: If the interactive "ex" mode vanishes, I wouldn't mind - but the batch mode I'd like to stay.

@webdesserts

I think most of the people who are defending "ex mode" are probably confusing it with: rather than Q. Honestly that's the reason I read the issue in the first place.

@jkinz
jkinz commented Sep 19, 2014

Been using vi since 1978.

The command line mode, eg ":" is incredibly powerful and I would never use any vi-type tool that does not support command line mode as that is where all, (my), the power editing is done.

However, ex mode, while useful, is mostly redundant with command line (":") mode,

@jvermillard

+1kill it

@sukima
sukima commented Sep 19, 2014

@ewindisch (OFF TOPIC): I'm intrigued by the idea of editing on screens that lack descent interactiveness. Like an LCD one liner or maybe an ssh session on an iPhone screen (max 10 lines and 20 columns) So learning to manipulate text in a line based editor like ex-mode seems useful. Would you mind expanding on that topic and suggestions on becoming a better power user on odd shell environments?

ON TOPIC: I have no investment in the NeoVim implementation or removal of this. I use Vim and the nvim site hasn't offered any reason (for me) why that should change.

@daenney
daenney commented Sep 19, 2014

Given that the premise of NeoVim is vim 'for the next generation', hopefully based on idea's of this millennium, not the past, I think Q/ex-mode is a primary candidate for removal. Keep things around for historical 'correctness' is fairly often a bad idea.

Everything that you can do in Q-mode can be done with other tools and I think most of the 'next generation' are far more likely to be familiar with those tools and reach for them instead of Q-mode.

It's also fairly telling that the second Google hit for vim ext mode is http://www.bestofvim.com/tip/leave-ex-mode-good/.

@Leimy
Leimy commented Sep 19, 2014

I use ed when I want ex-like stuff. And otherwise I'm an emacs user 99% of the time, but I do reach for vim from time to time. Advanced vim users are not the same people who know how to use "ed" and related command line editors well is the conclusion I've reached. Also there's sam for a more modern editor that follows the ed traditions a bit more closely than I think vim wanted to. I suspect at this point vim is pretty far from the original vi too.

@W4RH4WK
W4RH4WK commented Sep 19, 2014

i am using vim for years and everything (except java) - took a peak at ex-mode once and awhile but haven't used it ever.

@ZyX-I
Contributor
ZyX-I commented Sep 19, 2014

Before removing/adding any compatibility features:

  1. Do we need Neovim to be included by default in various distributions in some future?
  2. If yes then did anybody ask distribution maintainers whether they consider including Neovim by default and to which extent they will care about POSIX incompatibility of Neovim?
@umurgdk
umurgdk commented Sep 19, 2014

Im using vim as my daily editor. Configured to work like an IDE. Im using it for 5-6 years and I only know the name of this mode. I never used it. Never think about it. I would be happy if neovim get lighter by dropping unnecessary/creepy features.

UPDATE: vim wikibook points a code snippet using ex-mode from RPM package manager. http://en.wikibooks.org/wiki/Learning_the_vi_Editor/Vim/Modes#Ex-mode

@ZyX-I
Contributor
ZyX-I commented Sep 19, 2014

First question is more important because there is a not uncommon kind of persons which will blindly reject something which is not compatible to some standard, no matter how this standard is old and buggy and to which extent compatibility is kept. Cannot say how common this kind is spread in distribution maintainers.

@justinmk
Member

@ZyX-I We aren't anywhere close to POSIX compatible with Vi (we're going to remove Vi-compatibility) so I thought we already decided that this was not a concern. However, I don't see why that would affect inclusion in distro default installs. Is there a POSIX standard for nano or GEdit?

@tarruda
Member
tarruda commented Sep 19, 2014

ON TOPIC: I have no investment in the NeoVim implementation or removal of this. I use Vim and the nvim site hasn't offered any reason (for me) why that should change.

This thread already lists some reasons:

  • Simplify migration to the new UI architecture
  • Remove thousands of lines of C code supporting a feature that, from the POV of most users, is useless

On the other hand, here's a stupid ex-like python program that accepts a single filename, reads a bunch of commands from stdin and prints the result to stdout

#!/usr/bin/env python
# ex.py
import sys, neovim

file = sys.argv[1]
nvim = neovim.spawn(['nvim', '--embed', '-u', 'NONE'])
nvim.command('edit %s' % file)

for line in sys.stdin:
    nvim.command(line)

result = '\n'.join(nvim.current.buffer[:])
print result

With some enhancements we can make it behave a lot like the current ex implementation. And when nvim migrates to UIs running in a separate process that connect to nvim at startup, the above could be adapted(use neovim.connect instead of neovim.spawn) and a in-editor ex mode could be invoked by exiting the current UI and attaching the "ex program"

@tarruda
Member
tarruda commented Sep 19, 2014

@ZyX-I while inclusion by default in distros would be nice, I doubt this will ever happen. But consider this:

  • Emacs is still widely, but I don't think it is included in default installations of most well-known distros
  • Neovim editing model still applies to vi/vim, so I'm more than happy to using vim/vi for quick edits when sshing to a minimal server every once in a while. If I need more powerful features I simply install Neovim
@ZyX-I
Contributor
ZyX-I commented Sep 19, 2014

However, I don't see why that would affect inclusion in distro default installs. Is there a POSIX standard for nano or GEdit?

This means that these distro maintainers do not care about POSIX compatibility that much.

Emacs is still widely, but I don't think it is included in default installations of most well-known distros

I am not saying that you cannot develop a popular program without including it in distributions: in Windows world each first popular program is not included, with a few exceptions. But vi is included, Vim also is (and it is far more common, though some distributions use tiny version which is not very usable) and Neovim is positioning itself as a successor of Vim. So I am wondering whether this kind of adoption is among our goals. If it is not then removing Vi and POSIX compatibility, as well as Ex mode (which I am not using as I said) is OK.

@justinmk
Member

I am wondering whether this kind of adoption is among our goals

I think we should do as much as we can to make distro/package maintainers happy. If POSIX Vi makes distros happy we should distribute the Vim TINY build with Neovim and shell out to it if set cp is called.

Then distros can pretend Neovim is Vi-compatible and actual users can turn it off immediately, like everyone does.

@harsha-mudi
ed --> ex --> vi --> vim
 |--> grep 
 |--> sed        
 |--> diff

ex < script is pretty useful.
For writing the script however interactive ex is necessary.

@dlthomas

I use ex interactively rarely, but when I do it's important; I haven't ever felt the need to step back and forth between ex and visual mode. I would oppose killing that ability if it bought nothing, but it seems to be buying a fair amount, so I am satisfied with pushing ex out separately to talk over msgpack.

@justinmk
Member
ed --> ex --> vi --> vim
 |--> grep 
 |--> sed        
 |--> diff

@harsha-mudi I do not understand what you mean to communicate with this diagram. Neovim will support being "in the middle of a pipe"; ex mode isn't needed for this.

ex < script is pretty useful.

How is that functionality different than nvim -u <(cat script)?

@sethwoodworth
Contributor

I don't understand the reasoning for possibly keeping ex-mode. A world where NeoVim has replaced vim entirely in all package management systems on all platforms? vim-tiny is ~1mb on most platforms on debian. I personally would be happy to live in a world where vi is vim-tiny, used for scripts or guest users, and nvim is my IDE.

Would it be insane to package vi (vim-tiny) with NeoVim? Not so much for this conversation (which seems a foregone conclusion) but for future ones?

@dlthomas

A world where neovim has added some feature I want to use (either directly
or through a plug-in) and circumstances require ex style interaction.

On Fri, Sep 19, 2014 at 9:27 AM, Seth Woodworth notifications@github.com
wrote:

I don't understand the reasoning for possibly keeping ex-mode. A world
where NeoVim has replaced vim entirely in all package management systems on
all platforms? vim-tiny https://packages.debian.org/wheezy/vim-tiny is
~1mb on most platforms on debian. I personally would be happy to live in a
world where vi is vim-tiny, used for scripts or guest users, and nvim is
my IDE.

Would it be insane to package vi (vim-tiny) with NeoVim? Not so much for
this conversation (which seems a foregone conclusion) but for future ones?


Reply to this email directly or view it on GitHub
#1089 (comment).

@dlthomas

To my mind, the diagram is just a family tree...

On Fri, Sep 19, 2014 at 9:18 AM, Justin M. Keyes notifications@github.com
wrote:

ed --> ex --> vi --> vim
|--> grep
|--> sed
|--> diff

@harsh1kumar https://github.com/harsh1kumar I do not understand what
you mean to communicate with this diagram. Neovim will support being
"in the middle of a pipe"; ex mode isn't needed for this.

ex < script is pretty useful.

How is that functionality different than nvim -u <(cat script)?


Reply to this email directly or view it on GitHub
#1089 (comment).

@sethwoodworth
Contributor

There are two cases to argue for ex-mode

  1. Neovim adds a feature people want to use in ex-mode
  2. Neovim maintains ex-mode for existing script compatibility

In 1, the author has stated neovim just isn't going to have it. In 2, vi with ex still exists for the user's platform

@justinmk
Member

A world where neovim has added some feature I want to use (either directly or through a plug-in) and circumstances require ex style interaction.

Neovim will be totally scriptable, including shell pipe-and-filter workflow. ex-mode has nothing to do with this, it only provides an alternative interface that provides the minor features that @ZyX-I enumerated here: #1089 (comment)

@dlthomas

"The author has said X" is not a reason people can't argue for "not X".
You said you didn't understand the reasoning - apparently that was
disingenuous rhetoric.

As it happens, the author said the feature being dropped is the ability to
switch between ex mode and visual mode, which is more narrow than much of
this discussion has implied, and which I'm mostly fine with (it seems a
cost worth paying for the benefits).

On Fri, Sep 19, 2014 at 9:31 AM, Seth Woodworth notifications@github.com
wrote:

There are two cases to argue for ex-mode

  1. Neovim adds a feature people want to use in ex-mode
  2. Neovim maintains ex-mode for existing script compatibility

In 1, the author has stated neovim just isn't going to have it. In 2, vi
with ex still exists for the user's platform


Reply to this email directly or view it on GitHub
#1089 (comment).

@dlthomas

I am aware of what ex mode is. The primary feature (not "problem", as it
is labelled in the comment you link to) is precisely that the screen is not
updated between commands, while remaining smoothly interactive. As I've
said repeatedly, though, support for it as a separate executable is totally
fine by me.

On Fri, Sep 19, 2014 at 9:36 AM, Justin M. Keyes notifications@github.com
wrote:

A world where neovim has added some feature I want to use (either directly
or through a plug-in) and circumstances require ex style interaction.

Neovim will be totally scriptable, including shell pipe-and-filter
workflow. ex-mode has nothing to do with this, it only provides an
alternative interface that provides the minor features that @ZyX-I
https://github.com/ZyX-I enumerated here: #1089 (comment)
#1089 (comment)


Reply to this email directly or view it on GitHub
#1089 (comment).

@harsha-mudi

@justinmk

For writing ex scripts interactive ex is necessary.
It's like a repl for editing. Technically you don't need it, but the interactivity helps.

This reminds me about cmd.exe. How many "normal" users need it ?

@justinmk
Member

This reminds me about cmd.exe. How many "normal" users need it ?

@harsha-mudi I'm just trying to understand the use case. I definitely am not advocating that any feature should be removed because it's esoteric or weird. I am trying to understand what is compelling about this feature.

It's like a repl for editing. Technically you don't need it, but the interactivity helps.

I don't understand what REPL features are provided by ex mode that are not provided by Vim : prompt. Can you list them?

I use :Runtime from vim-scriptease and :QuickRun from vim-quickrun for REPL-like workflow when developing vimscripts. Have you tried them?

@Shougo
Contributor
Shougo commented Sep 19, 2014

Ex-mode is this?

                    *Q* *mode-Ex* *Ex-mode* *Ex* *EX* *E501*
Q           Switch to "Ex" mode.  This is a bit like typing ":"
            commands one after another, except:
            - You don't have to keep pressing ":".
            - The screen doesn't get updated after each command.
            - There is no normal command-line editing.
            - Mappings and abbreviations are not used.
            In fact, you are editing the lines with the "standard"
            line-input editing commands (<Del> or <BS> to erase,
            CTRL-U to kill the whole line).
            Vim will enter this mode by default if it's invoked as
            "ex" on the command-line.
            Use the ":vi" command |:visual| to exit "Ex" mode.
            Note: In older versions of Vim "Q" formatted text,
            that is now done with |gq|.  But if you use the
            |vimrc_example.vim| script "Q" works like "gq".

Yes, this mode is useless.

#1049 (comment)

I cannot understand the @tarruda comment.

Any reason ex mode still exist? I had plans to drop it completely as it seems to be completely useless next to the command window

@tarruda wants to drop command-line window(q:) feature?

@justinmk
Member

wants to drop command-line window(q:) feature?

@Shougo No, he means that the command window provides the same functionality as ex mode, so ex mode is not needed.

@Shougo
Contributor
Shougo commented Sep 19, 2014

I found some plugin uses Ex-mode.

https://github.com/kana/vim-vspec/blob/21d51b55a920ed43e0a007d8d6b3561b2cddcc2e/bin/vspec#L59

But it launches "vim", so it cannot launch "nvim".

@Shougo
Contributor
Shougo commented Sep 19, 2014

@Shougo No, he means that the command window provides the same functionality as ex mode, so ex mode is not needed.

Thanks. I underastand.

Oh, I use Ex-mode in my plugin.

https://github.com/Shougo/neobundle.vim/blob/master/bin/neoinstall

Although it does not support "nvim" command.

@justinmk
Member

nvim -e will be supported. Q ex-mode will not.

@Shougo
Contributor
Shougo commented Sep 19, 2014

I think current Ex-mode is used like Emacs's batch mode to use Vim as Vim script interpreter.
I think neovim can remove Ex-mode, but neovim must provide batch mode for those script.

@Shougo
Contributor
Shougo commented Sep 19, 2014

I get it. It is good.

@Valloric

Kill it with fire.

@Kazark
Kazark commented Sep 20, 2014

I haven't read this entire thread, but in my opinion part of the success of NeoVim thus far is due to its fearlessness. I, as a long time Vim user, am getting tired of some of the cruftiness and archaic stuff in Vim. But Vim is probably number one in my love of computer programs. However, it is in the best interest of the ongoing life of the true essence of Vim that non-essential parts die. Vim suffers from a complexity problem. So my vote, if it matters at all, is burninate!

@c4pt0r
c4pt0r commented Sep 20, 2014

burn it!

@lydell
lydell commented Sep 21, 2014

Would it be possible to implement ex mode as a plugin?

@wizztjh
wizztjh commented Sep 22, 2014

+ 1 to make ex mode a plugin

@tarruda
Member
tarruda commented Sep 22, 2014

Would it be possible to implement ex mode as a plugin?

It would be possible to implement an user interface that behaves like the current ex mode. Switching between normal mode and ex mode could be achieved by detaching one UI and attaching another

@matthiasbeyer
Contributor

I guess adding ex mode as plugin, as @tarruda stated, should be fine for us ex-mode lovers. At least I am fine with this! What about you others?

@haya14busa

I guess it's a little off-topic, but let me post in this issue.

If neovim will remove Ex-Mode, how about removing vim -y too?
In other words, how about removing :h 'insertmode' which is used for evim?

Sorry, I'm not familiar with neovim development nor source code of neovim, but I think the code could be simpler if removing it and 'insertmode' is also close to useless enough to remove it.

@Kazark
Kazark commented Nov 6, 2014

@justinmk @Shougo Okay, so to confirm, q: will continue to be supported?

@justinmk
Member
justinmk commented Nov 6, 2014

@Kazark Yes, without question.

@andrewrk

There's a reason that the first thing that happens when you (probably accidentally) enter ex mode is that it tells you how to leave it. I'll vote with my dotfiles project.

@habash1986

Kill it without a question. Neovim vision is simple: kill outdated features so the project can move forward, IMHO this question shouldn't be asked at the first place, this is Neovim not Vim, it's like asking if Aimga should be supported in Neovim.

@elmart
Member
elmart commented Dec 17, 2014

It's not that simple. We also want a smooth vim->neovim transition, so that people don't miss anything they are actually using. Definition of "outdated" is not the same for everyone, and so removals should be clearly justified. In this particular case, I have not a clear opinion.

@tarruda
Member
tarruda commented Dec 17, 2014

I no longer in rush for removing this. The main reason I wanted to do it was because it made merging #781 hard, but #1605 deprecated it and introduced a new UI module that has no problem with ex mode redrawing

@christopherdumas

Still, killing ex-mode might be a good idea.

@dorfsmay

I use ex commands often to do global changes etc... And even more often from bash scripts. I don't know of any other editor that can be used to do advanced changes to a file in an automated fashion. The fact that you can use the same command online and from a script is one of the advantage of vi/vim.

@christopherdumas

@dorfsmay BTW, nvim supports being in pipes now.

@justinmk justinmk locked and limited conversation to collaborators Dec 26, 2014
@justinmk
Member

This issue isn't about ex commands.

@justinmk
Member

I guess we can skip this.

@justinmk justinmk closed this Sep 23, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.