If I have this line in my vimrc
au VimLeave %bdelete
Then whenever vim starts it says
--- Auto-Commands ---
Press ENTER or type command to continue
I have that line there to empty the buffers from gvim, because new gvim instances have massive :ls output from previous runs. Notably, gvim doesn't actually produce this prompt.
Obviously I can set this instance up to only occur during gvim startup and not console vim, but I'd like to understand this rather than avoid it. Mostly I'm confused that VimLeave seems to cause things to happen on startup.
TIA
Altreus
The problem is that this is an incomplete :autocmd definition, so Vim attempts to list all VimLeave autocommands defined for the pattern %bdelete. You need to specify the any file pattern to make it work:
au VimLeave * %bdelete
Also, check whether you have % in your 'viminfo' option; that one enables the saving and restoring of the buffer list you're complaining about. The f option of file marks may also result in buffers being restored; you could try :set viminfo+=f0.
New Vim instances don't inherit the buffer list of the previous instance unless you add % to the viminfo option.
Setting that option to a sane value will remove the need for your broken fix. Reading the documentation before adding options to your config will prevent you from similar issues.
See :help 'viminfo'.
Related
I have a problem with syntax highlighting in gvim.
i have the following command in my vimrc file:
autocmd BufNewFile,BufRead *.v,*.vs,*.va set syntax=verilog
However if i'm in gvim reading a file - "a.txt" and i also have "b.txt" open on split, when i click on b and then return to a , the syntax highlighting is gone after the click.
someone tried to explain to me that the autocmd not always running.
any ideas
The BufRead option only applies when reading a file into a new buffer, so it makes sense that simply switching between splits won't trigger the auto command. The file has already been read into the buffer; it's not read again unless you close and reopen it.
You want the option BufEnter, as it triggers on entering a buffer. Your new command should then look like:
autocmd BufNewFile,BufRead,BufEnter *.v,*.vs,*.va set syntax=verilog
As a side note, it's probably better to use filetype instead of syntax, as syntax won't affect indentation rules, if there are any. Or even better, use a plugin to get everything set up automagically without needing explicit autocommands in your .vimrc. Just from a quick Google, this plugin pops up a bunch.
I found out all the settings in .vimrc actually are stored in session file. If that is the case, why vim -S session load .vimrc again? Why does vim design like this?
I have some commands in .vimrc and when I use vim -S, it causes problems because those commands should only be run once, not twice.
Thanks a lot.
My problematic vimrc block in mksession:
let g:netrw_banner = 0
let g:netrw_liststyle = 3
let g:netrw_browse_split = 4
let g:netrw_altv = 1
let g:netrw_winsize = 25
augroup ProjectDrawer
autocmd!
autocmd VimEnter * :Vexplore
autocmd TabNew * call feedkeys(":Vexplore\<CR>", 'n')
augroup END
What a session stores
What gets stored in a saved session is controlled by the :help 'sessionoptions' option. It's defaults are very conservative, aimed at not losing any ad-hoc mappings or changed options.
However, most users place their settings in the ~/.vimrc, use plugins and filetype plugins, and generally do not make up mappings or change settings on the fly. If that kind of workflow also applies to you, I'd suggest to remove the following values:
:set sessionoptions-=globals
:set sessionoptions-=localoptions
:set sessionoptions-=options
You may also want to remove buffers and resize, too. That change not just reduces the size of the saved session, it also prevents that an old session overrides any configuration that you've changed in your ~/.vimrc in the meantime.
vimrc reload
So, your ~/.vimrc isn't directly reloaded, but (with default 'sessionoptions'), a lot of options and variables are restored.
By using :augroup followed by :autocmd!, you've also avoided a frequent beginner's mistake: Without that, the autocmds would be redefined on each reload of your ~/.vimrc. The :autocmd! prevents that, and the :augroup makes that apply just to your own group.
sessions and special (plugin) buffers
A session should store all currently open buffers. Regular buffers contain file contents, and these can easily be reloaded when a session is opened again. Unfortunately, plugins (mis-)use buffers for their user interfaces (e.g. a sidebar, as by the netrw plugin), and Vim's session handling is not clever enough to distinguish between the two. But those plugin buffers have no corresponding file; instead, the plugin used command to directly build and modify its contents, often with the help of plugin variables that - see above - either are or aren't saved and restored.
Plugins would have to explicitly handle session restoration; I don't remember any plugin that does this, though. So often, you'll see an "empty" window restored, and the plugin may or may not recognize or reuse that. (And I think that's the problem you're asking about.)
The general recommendation is to close any plugin buffers before saving a session, either manually, or by writing a custom :Mksession wrapper that automates this for you. On session reload, your configuration may then create a fresh, functional plugin window again. (Or you have to trigger that manually.)
Not all the settings from the vimrc are stored in the session file (see :h mksession). The settings you see are specified in the :h sessionoptions option.
You can load a session without loading the vimrc by using vim -u NORC -S; however, you'll quickly see you're missing your desired baseline settings.
Which commands should only be run once? There are specific ways to prevent commands from running twice unnecessarily when sourcing your vimrc.
For instance, if the command that should only be run once is an autocmd you should use an augroup like so:
augroup vimrc
autocmd! " Remove all vimrc autocommands
au BufNewFile,BufRead *.html so <sfile>:h/html.vim
augroup END
Due to various reasons, I run Vim at sixteen-colors, synced w/ my terminal's colors. In a recent Vim update, I've had to rework my "~/.vimrc" completely to get it back into running order on Linux.
Initially I was shocked to find that this simple line did not work (even w/ "syntax on" preceding it):
:highlight Comment ctermfg=White
I'm also using a "LineNr" ctermfg. No matter where I placed/stacked the "Comment" ctermfg, it didn't work, or interfered w/ everything else sourcing correctly (ie, placed in the same line w/ "LineNr"). However, I found that calling "Comment" after a buffer had loaded would make the comments appear as intended.
I am new to autocmd in Vim (and want to know how it works, anyways). Is there an "autocmd" call that I can have in my "~/.vimrc" that will run the aforementioned line of code immediately after a buffer has loaded?
I have tried several iterations (BufWritePre, BufWritePost, etc.) and been unsuccessful. This was my previous attempt:
autocmd BufWinPost * :highlight Comment ctermfg=white
Don't resort to :autocmd without reason; search harder for the root cause!
Your description lacks specifics; I guess your chosen colorscheme (or a plugin, but no sane plugin should interfere with the default highlightings) overrides your custom one for Comment. You can check who defined this via
:verbose highlight Comment
If this points to your colorscheme, you simply need to execute your :highlight command after it. For this, you need to understand :help initialization, and maybe check the output of :scriptnames. If you have a :colorscheme foo command in your ~/.vimrc, it should be as simple as putting the :highlight command after it.
You do need an :autocmd if you switch colorschemes on the fly, as most colorschemes override the basic Comment definition. The correct event and pattern for that would be ColorScheme *
If I do a quick :h autocmd-events, I find the the event BufWinPost does not exist. I think, you want BufWinEnter instead. The autocmd you wrote should work, except for the :. HTH
Sometimes I need to substitute across multiple buffers. For the purpose I use :bufdo %s/old/new/gec. Recently I noticed that the command fails when there is non-modifiable buffer in the buffer list (in my case it's opened file explorer/netrw). After running the command vim leaves me with E21: Cannot make changes, 'modifiable' is off and opened Netrw window.
Are the ways to :bufdo only on modifiable buffers? I've already tried :bufdo!, but the behaviour was the same (just without showing the error).
UPDATE
I find the line of .vimrc that poses this problematic behaviour:
let g:netrw_liststyle=3
I don't know what the magic here, but when I set this option neither of the suggested solutions/commands work for me. Now, the question is how to keep this line and make the :bufdo behaviour skip the buffer created by Netrw.
Well, if :bufdo sil! :%s/old/new/gec does not work for you (this silently ignores errors). you need to wrap the command into an if statement. Something like this:
:bufdo if &ma | :%s/old/new/gec | endif
which checks for each buffer, if it is modifiable and only then attempts to replace old by new.
Note: You might also want to check for the 'readonly' option in addition to the 'modifiable' setting.
I was used to use vimdiff and loading the compared files.
Now, on vimdiff execution, it happens:
"a" [readonly] 5454L, 269796C
"b" [readonly] 241L, 10170C
Press ENTER or type command to continue
The only configuration change is the introduction of these two autocmd instructions:
autocmd BufNewFile * call s:Function()
autocmd BufReadPre * call s:Function()
Can this be a normal behavior? Can it be a mistake of mine? Can be something depending on Vim versioning? Can the desired configuration change be combined with a straightforward vimdiff load (no ENTER key needed to continue)?
The dreaded hit-enter prompt is usually triggered by additional :echo[msg] commands, here inside your s:Function(). Either remove them, or silence the output via :silent:
autocmd BufNewFile * silent call s:Function()
If you want to keep whatever messages are displayed in your function, you can set your 'cmdheight' option higher to allow displaying more messages before the "hit enter" prompt appears. This, and other suggestions here: http://vim.wikia.com/wiki/Avoiding_the_"Hit_ENTER_to_continue"_prompts