[vim/vim] VIM should respect SIGINT (#1720)
lostmsu
A significant milestone was achieved today: Stack Overflow question "How to exit VIM" reached 1,000,000 views.
It looks like the time has come for a radical change: make VIM finally behave like any other sane program and respect UNIX SIGINT signal.
I propose the following behavior:
- if there are no unsaved changes, simply exit
- if there are changes, switch to command mode, and print the same warning one gets when doing :q
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
erik falor
What do you propose to do with the behavior currently invoked by CTRL-C?
:help CTRL-C
Stack Overflow is clearly doing a fine job of educating the Google generation how to exit Vim. Is this truly something that demands a radical change?
Roy Wellington Ⅳ
This is related to #1719; (I proposed coloring the keystrokes s.t. they stand out, and maybe normalizing the spacing across locales to two spaces around the keystrokes)
Not every "sane program" respects SIGINT by quitting. For example, bash and zsh, and ipython use it to abort the current command, instead of exiting. (In fact, in programs that lack this behavior, such as mongo, I find it rather annoying.) I'm not sure if vim falls into this category, but I think it's fair to say it might.
Gary Johnson
> A significant milestone was achieved today: Stack Overflow question "How to
> exit VIM" reached 1,000,000 views.
>
> It looks like the time has come for a radical change: make VIM finally behave
> like any other sane program and respect UNIX SIGINT signal.
>
> I propose the following behavior:
>
> • if there are no unsaved changes, simply exit
> • if there are changes, switch to command mode, and print the same warning
> one gets when doing :q
attempts to stop what it's doing but does not exit. If it happens
to stop just before I type the CTRL-C, it does not exit but prints
the statement,
Type :quit<Enter> to exit Vim
This is exactly the behavior I would expect and which I want. Your
proposal would make it too easy to exit Vim inadvertently.
Regards,
Gary
vim-dev ML
> A significant milestone was achieved today: Stack Overflow question "How to
> exit VIM" reached 1,000,000 views.
>
> It looks like the time has come for a radical change: make VIM finally behave
> like any other sane program and respect UNIX SIGINT signal.
>
> I propose the following behavior:
>
> • if there are no unsaved changes, simply exit
> • if there are changes, switch to command mode, and print the same warning
> one gets when doing :q
attempts to stop what it's doing but does not exit. If it happens
to stop just before I type the CTRL-C, it does not exit but prints
the statement,
Type :quit<Enter> to exit Vim
This is exactly the behavior I would expect and which I want. Your
proposal would make it too easy to exit Vim inadvertently.
Regards,
Gary
R0b0t1
> A significant milestone was achieved today: Stack Overflow question "How to
> exit VIM" reached 1,000,000 views.
>
> It looks like the time has come for a radical change: make VIM finally
> behave like any other sane program and respect UNIX SIGINT signal.
>
> I propose the following behavior:
>
> if there are no unsaved changes, simply exit
> if there are changes, switch to command mode, and print the same warning one
> gets when doing :q
>
different from GUI programs. Unless someone is forced to use vi (or
vim) they generally catch on to the fact it is a command interpreter
that displays text, as opposed to a text editor in the usual sense.
In light of Mr. Wellington's and Mr. Johnson's comments - notably, the
realization that Vim is a command interpreter - I don't think it makes
sense to change anything.
vim-dev ML
> exit VIM" reached 1,000,000 views.
>
> It looks like the time has come for a radical change: make VIM finally
> behave like any other sane program and respect UNIX SIGINT signal.
>
> I propose the following behavior:
>
> if there are no unsaved changes, simply exit
> if there are changes, switch to command mode, and print the same warning one
> gets when doing :q
>
different from GUI programs. Unless someone is forced to use vi (or
vim) they generally catch on to the fact it is a command interpreter
that displays text, as opposed to a text editor in the usual sense.
In light of Mr. Wellington's and Mr. Johnson's comments - notably, the
realization that Vim is a command interpreter - I don't think it makes
sense to change anything.
James McCoy
It looks like the time has come for a radical change: make VIM finally behave like any other sane program and respect UNIX SIGINT signal, as well as the default combination used to send it.
Vim already understands how to shutdown gracefully when you kill it with SIGTERM. SIGINT is for interrupting long-running actions or cancelling out of insert mode.
—
You are receiving this because you commented.
lostmsu
@fadein , consider this: assuming a typical developer earns $0.5/min, and assuming it takes about 2 minutes to google "How to exit VIM", in past 5 years lacking this feature costed $1kk to the world's economy.
—
You are receiving this because you commented.
James McCoy
@lostmsu That logic implies that developers never spend time learning the tools of their trade, of which a good editor is one tool. Learning Vim, which is far more than learning how to exit, is more than worth the investment.
—
You are receiving this because you commented.
erik falor
@lostmsu, perhaps that is true, but consider how much more beneficial those typical developers become to the world economy once they attain proficiency with Vim.
—
You are receiving this because you commented.
Christian Brabandt
As Gary, I rely on ctrl-c to not accidentally quit vim and that would really annoy me, if it did. And since there does not seem consensus to change that behavior, I am closing this. There is also #1719, feel free to comment there and suggest improvements.
—
You are receiving this because you commented.
Christian Brabandt
lostmsu
@chrisbra , as a note: it looks like you are biased against doing that change for some reason. There are plenty of requests in this issue tracker, that are actively discussed, that stay open way longer than 10 hours before anyone decides, that the consensus is impossible to reach on the matter.
I wonder also if most people exaggerate their annoyance by accidentally exiting vim after hitting Ctrl+C when some long operation just completed. First, people usually not press Ctrl+C unless operation takes noticeable time, which renders probability of it ending when Ctrl+C is about to be pressed very low. Second, in case there's no unsaved change, it should be very easy to restart vim by simply hitting Up followed by Enter. Third, I am sure there are similar scenarios, which lead to annoying accidental actions, which are universally recognized as being OK.
—
You are receiving this because you commented.
lostmsu
Learning Vim, which is far more than learning how to exit, is more than worth the investment.
That statement is opinionated. My statement on $1kk is factual.
—
You are receiving this because you commented.
Dominique Pellé
> I wonder also if most people exaggerate their annoyance by accidentally exiting vim
> after hitting Ctrl+C when some long operation just completed.
Interrupting long actions with Ctrl-C is a well known Vim feature, which is documented
(see :help CTRL-C). Changing this behavior would be jarring to many users.
It would annoy me very much at least if Vim exits when pressing Ctrl-C.
—
You are receiving this because you commented.
fritzophrenic
Vim is also used on many different platforms, notably including Windows. It also runs in a GUI on Linux systems, it is not limited to being a terminal application only. Exiting the app when pressing CTRL+C (the normal shortcut for "copy" in most GUIs and Windows in particular) would be extremely jarring and unexpected. We'd get SO many bug reports for that. Making the behavior intentionally drastically different between the GUI interface and the terminal interface would be extremely annoying as well and we'd get more bug reports for that. This idea was poorly thought out and will never work, I agree with it being closed quickly.
—
You are receiving this because you commented.
lostmsu
@fritzophrenic , your post is an additional example, that some people wanting to close this are rushed to do so. First, this discussion only happens to mention Ctrl+C a lot only because it is the default shortcut to send SIGINT on many operating systems. Since Windows GUI does not send SIGINT when you press Ctrl+C, it should not close the editor.
Second, as mentioned above by other people, Ctrl+C is used for interrupting processes already, and it should continue doing so unless there's no in-progress operation to interrupt (which is also an answer to @dpelle's post).
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
fritzophrenic
The average person won't care at all that Linux sends SIGINT when they press CTRL+C but Windows doesn't. All they'll care about is that in Linux they lost 20 minutes re-opening Vim and setting up all the windows and files they had open when all they wanted to do was copy something in exactly the same way they do it in Windows. The user experience should not depend on what goes on under the hood, wherever possible.
—
You are receiving this because you commented.
Christian Brabandt
@lostmsu
We are reaching bike shedding level here and it is obvious that there are a lot of different views. My fear would be, while making it easier for a new-user to quit Vim this would go against the habbit of normal or power users and that is not worth it IMHO. So I decided to close it. That decision stands.
—
You are receiving this because you commented.
R0b0t1
rather interesting:
https://stackoverflow.blog/2017/05/23/stack-overflow-helping-one-million-developers-exit-vim/.
It seems like it supports the idea that despite the question's
popularity, most people can figure out how to exit the editor and it
is only certain demographics that have problems with the editor.
However, they still find the answer.
A far more interesting but harder to find statistic is how many people
resort to closing the terminal emulator or killing the vim process
from another virtual terminal. I have heard of this happening but the
number is likely vanishingly small.
vim-dev ML
erik falor
After reading the comments on that blog post, I think the problem just comes down to the fact that a modal editor is a foreign concept to ordinary users.
The discussion about demographics, while fascinating, is too imprecise to draw any meaningful conclusions from. The simple fact that SO is an English-language website really skews any demographic inferences which may be drawn from it. And
As far as reports of people closing the terminal out of desperation, I got the sense that most of those comments were in jest. I'm sure that has been done by someone, somewhere, but the tone of the whole discussion was disparaging towards Vim. I came away with the impression that this question exists in SO not as an earnest plea for help, but rather as a barb in the ongoing holy war. I freely admit that this question has been helpful to somebody out there as a side-effect, but after surveying the comments from the peanut gallery I can't help but think that it exists to support the argument that "heh heh, Vim is such a backwards program that 1M people can't figure out how to exit from it, lolz."
—
You are receiving this because you commented.
Nikolai Aleksandrovich Pavlov
I wonder also if most people exaggerate their annoyance by accidentally exiting vim after hitting Ctrl+C when some long operation just completed. First, people usually not press Ctrl+C unless operation takes noticeable time, which renders probability of it ending when Ctrl+C is about to be pressed very low. Second, in case there's no unsaved change, it should be very easy to restart vim by simply hitting Up followed by Enter. Third, I am sure there are similar scenarios, which lead to annoying accidental actions, which are universally recognized as being OK.
None of the above statements is true for me:
- I sometimes press
<C-c>because I made a mistake and want to correct it, regardless of how much time would operation take to finish. Though this is not very often it happens. - Hitting up followed by
<Enter>is highly unlikely to restart Vim and almost never will restart it correctly. First, if you were actually using Vim in a terminal a lot you would new about:suspend/<C-z>; sovimis not the previous command after<C-c>with my workflow, it isfgand there will be a bunch of other commands before, sometimes even another Vim. Second, my normal operation is “open all project files in editor at once then work there for large amount of time”. Killing Vim means loosing jumps, sometimes window layout, current buffer. Not to mention plugin-specific buffers which you do not invoke from command-line. And you did mention unsaved changes, this is also significant. - Where are examples?
If you were ever using Vim only as oneshot editor “open that file, quickly do some changes, save and exit” it does not mean other users do the same.
And interactive terminal apps with more or less complex UI (mostly various REPLs and shells) are more likely to exit after <C-d> then after <C-c>.
Last, but not least: people hitting <C-c> annoyingly to exit Vim and then going to Google, unable to read and follow “Type :quit to exit Vim” or find another way around are too dumb to be CLI users. It would be much better if they never opened a shell and it is definitely not what Vim should care about. Ipython, for example, does not even provide this message (it is one of the interactive terminal apps which exit at <C-d>).
—
You are receiving this because you commented.
依云
I think the problem just comes down to the fact that a modal editor is a foreign concept to ordinary users.
I don't think so. It might be Vim is the most popular terminal UI application among others. IMO, means to stop/abort, not to quit. To quit I might try to read the interface for a clue, or try (for interactive shells) and q(for UI without input areas, like htop & mutt).
mutt actually asks to quit or not on , which is annoying, since I mean to stop whatever mutt is currently doing, but not to quit.
—
You are receiving this because you commented.
Hisashi T Fujinaka
Hisashi T Fujinaka - ht...@twofifty.com
BSEE + BSChem + BAEnglish + MSCS + $2.50 = coffee
vim-dev ML
—
You are receiving this because you are subscribed to this thread.
R0b0t1
> Why can't you use nano like other people who don't understand vi or vim?
>
or VISUAL environment variable to contain a program. Sometimes the
default is vi or vim when it would probably make more sense to have it
be something like nano. Git is the main program that comes to mind.
Tony Mechelynck
in very similar manner to similar commands: on Linux, Ctrl-Q, and
often but less reliably clicking the [x] at the end of the window
titlebar, will make them exit gracefully.
For interactive console programs it is different: to exit bash you
type exit<Enter>, which brings you back to the calling shell if there
was one, or logs you out if there wasn't. To exit Lynx you hit q to
exit with an are-you-sure prompt, or Q to exit immediately. To exit
ftp you type quit<Enter> or exit<Enter> or bye<Enter>
Vim is both a GUI and a console program and runs identically in both;
in fact I suspect that Vim (and vi) were developed first as console
editors, and that GUI mode was added afterwards, which explains why
gvim could be regarded as a console-mode program running in its own
GUI-like console. So you exit gvim or vim the same way, and it happens
to be :qa<Enter> (which will prompt you if you have unsaved files) or
:qa!<Enter> (if you want to |abandon| anything unsaved).
In order to use Vim efficiently, you have to learn how to. For this,
you need a willingness to run the vimtutor suite and enough curiosity
to peruse the online help (which is the best available help system for
personal computer utilities AFAIK). Vim was developed over the years,
based on Vi which evolved over previous years from a time when the
usual interface with a computer was a teletype console which could not
move backward. So it has it own quirks, which, after some time, feel
"natural" to people who have taken the time to learn them. So what if
Vim behaves differently than Notepad or geditf course it does! It can
do a lot of things that Notepad or gedit cannot, so it's just natural
that it should be different.
Best regards,
Tony.
> --
> You received this message from the "vim_dev" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups
> "vim_dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to vim_dev+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
R0b0t1
> @r0b0t1,
>
> After reading the comments on that blog post, I think the problem just comes
> down to the fact that a modal editor is a foreign concept to ordinary users.
>
I'm just trying to put the statistic of 1m views into context.
> The discussion about demographics, while fascinating, is too imprecise to
> draw any meaningful conclusions from. The simple fact that SO is an
> English-language website really skews any demographic inferences which may
> be drawn from it. And
>
form of selection bias that the OP was using: the question was viewed
1m times, but how many people didn't need to view it because they had
no problem? Conversely, how many people didn't view it because vim was
so incomprehensible that they had no idea what to search for?
Not to go off on much of a tangent, but a lot of A/B testing an UX
development seems to fall prey to this, even from large companies like
Google. They forget to look at what they didn't test or what isn't
explicitly represented in their data. Generally this leads to changes
for no discernable reason from the user's standpoint.
> As far as reports of people closing the terminal out of desperation, I got
> the sense that most of those comments were in jest. I'm sure that has been
> done by someone, somewhere, but the tone of the whole discussion was
> disparaging towards Vim. I came away with the impression that this question
> exists in SO not as an earnest plea for help, but rather as a barb in the
> ongoing holy war. I freely admit that this question has been helpful to
> somebody out there as a side-effect, but after surveying the comments from
> the peanut gallery I can't help but think that it exists to support the
> argument that "heh heh, Vim is such a backwards program that 1M people can't
> figure out how to exit from it, lolz."
>
emulator it had run in. This happened maybe 3 times. What I was trying
to point out above is that it's really hard to get a feel for anything
like this, and these are situations which *do* actually indicate
usability concerns.
That 1m people viewed a post which succinctly answered their question
is almost meaningless.
vim-dev ML
—
vim-dev ML
emulator it had run in. This happened maybe 3 times. What I was trying
to point out above is that it's really hard to get a feel for anything
like this, and these are situations which *do* actually indicate
usability concerns.
That 1m people viewed a post which succinctly answered their question
is almost meaningless.