Hot answers tagged


A process can block, ignore, or catch signals. You can see how a given process handles signals with this shell command: $ cat /proc/PID/status | grep -E '^Sig(Blk|Ign|Cgt):' │ │ │ │ │ └ caught signals │ └ ignored signals ...


For some unknown reason it's :h hl-MoreMsg. BTW. If you're unhappy with some colors it might be worth to give a try to a different color scheme, as there's a ton of them.


As you can see in :help BufUnload: NOTE: When this autocommand is executed, the current buffer % may be different from the buffer being unloaded <afile>. So you should use getbufvar() to access the contents of that variable for the buffer being unloaded. if getbufvar(+expand("<abuf>"), "ipynb_file") != "" (Using ...


:wa and :wqa will write all changed buffers; from :help :wqa: :wqa[ll] [++opt] :wqa :wqall :xa :xall :xa[ll] Write all changed buffers and exit Vim. If there are buffers without a file name, which are readonly or which cannot be written for another reason, Vim will not quit. Since your ...


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


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.


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


The current buffer and file is behind <afile>, not %

Only top voted, non community-wiki answers of a minimum length are eligible