Vim: how to make :q shut up about unvisited files?

Question

When Vim is invoked on multiple files from the command line, then if any of those files have not been visited with :next or via buffer switching, the :q command pointlessly warns about the situation with a message like "43 files left to edit" and refuses to quit, even though nothing has been modified. Is there a way to eliminate this behavior?

In the :help documentation, we have:

:q[uit]             Quit the current window.  Quit Vim if this is the last
                    window.  This fails when changes have been made and
                    Vim refuses to abandon the current buffer, and when
                    the last file in the argument list has not been
                    edited.
                    If there are other tab pages and quitting the last
                    window in the current tab page the current tab page is
                    closed tab-page.
                    Triggers the QuitPre autocommand event.
                    See CTRL-W_q for quitting another window.

which just confirms the behavior: "fails ... when the last file in the argument list has not been edited".

The forced execution :q! will work, but is not acceptable because it will discard unsaved changes.

The documentation does not seem to mention that if the command fails due to the last file not having been edited, simply repeating the command will then force it.

Answer 1

The :cabbrev-answer has downsides because the abbreviation is active everywhere in the : command line, even if restricted to that type of command using the <expr> mechanism.

Ideally, Vim would have a command execution hook: a piece of code that could be executed each time a command is run, or at least an interactive command. That hook could rewrite the command.

Turns out, we can use :autocmd as a close facsimile. Vim's :autocmd has useful hooks, one of which is QuitPre. And so, with this simple line in the .vimrc, all seems good:

:au QuitPre * qa

When the QuitPre event is triggered on any buffer, we issue the qa command. This effectively rewrites q to qa.

Various experiments are confirming to me that it has the right behavior, and fixes :x also. When multiple files are being edited, and there are no changes, both :x and :q quit, as desired.

When there are unsaved changes, :q still fails, and :x fails if other buffers are unsaved.

A curious behavior occurs with :q!, though all seems well nonetheless. When there are unsaved changes, it quits as expected. However, Vim's admonishments that there are unsaved changes briefly flash on the display for a fraction of a second.

Answer 2

Yet another alternative is to :set confirm. Then :q will prompt in this case, and you hit y (or a localized equivalent) to continue. No new habits.

Answer 3

I have found a better solution than :au QuitPre * qa.

Vim's complaint that unedited files remain is not literally based on that stated condition. The internal condition is actually "has the last file been visited"?

So that is to say, if we open a bunch of files:

vim *.c

and then do this:

:last
:q

it will quit. The warning:

E173: 57 more files to edit.

is not a lie per se, but it is misleading about the condition on which it is based. It should really say:

E173: There are 57 unvisited files and you've not visited the last one.

And so, the following solution presents itself:

:au QuitPre * last

That's it! Before quitting, run the :last command to visit the last file.

I have tested this and have not noticed any side effects. For a brief moment, you may catch glimpse of the editor's status line switching to showing the name of the last file before just prior to termination.

I discovered a funny thing while experimenting with this.

If you start Vim with no file argument at all (no file is being edited, just a buffer), the :last command produces this diagnostic:

E163: There is only one file to edit

E163 should say:

E163: No files are being edited, therefore there is no last file

No such error is not produced if you edit exactly one file and use :last, which makes sense: if you're editing one file, that's the last file.

In any case, even with the au QuitPre * last installed, I've not seen even the slightest glimpse of this E163 error message when quitting a no-file edit session.

Edit: An unwanted side effect of :au QuitPre last has been discovered, which is quite nasty.

I sometimes edit a fairly large file of more than 80,000 lines, for which the BufEnter action runs a custom Vim script for folding calculations. This takes a bit of time to run.

Now, when I save the file and exit with :x, there is a big delay.

If I take out the :au QuitPre last from my .vimrc, then :x is virtually instant.

It seems that Vim does not optimize :last when that is a no-op; it is behaving as if entering that buffer.

I can reproduce this issue by typing :last. Vim freezes for many seconds, even though nothing is being edited but that file.

An acceptable solution to this problem must avoid this side effect. Perhaps the command dispatched by QuitPre should be a conditional which executes last only if there are two or more buffers.

That solution is this:

:au QuitPre blast

Switching to the last buffer using :bl{ast} rather than :last does not exhibit the above problem. With bl, Vim does not re-execute the time-consuming folding-related scriptology if that buffer is already the one being edited. Yet this QuitPre hook still has the desired effect of suppressing the warning about unvisited files.

Answer 4

The :qa command does what I want.

By itself, that would not be an acceptable solution; however, it's possible to turn :q into :qa using

:cabbrev q qa

This accompanying definition also helps:

:cabbrev x xa

allowing :x to be used to save and quit a change even though there are unedited buffers.

Unfortunately, the abbreviatiosn are active throughout the : command line and other contexts. Based on user filbranden's excellent hint in the comments below, the following refinement ensures that the abbreviations are only expanded in a colon command:

:cabbrev <expr> q (getcmdtype()==":"?"qa":"q")
:cabbrev <expr> x (getcmdtype()==":"?"xa":"x")

This achieves the effect as if the abbreviation didn't exist outside of the : command line. Still, the mitigation is not perfect because q, if it appears as a delimited in the right ways, expands to qa almost anywhere in the command line. If we try to edit a file called q using:

:vi q

the abbreviation expands and qa is opened instead.