I would like to always open a vertical split with Explore whenever I open a file in vim. So I added the following list to my init.vim
topleft vsplit | :vertical resize 30 | :Ex
however I get the following error message.
Not an editor command: :Ex
however I get the following error message.
So the command is invalid. :Ex is provided by a plugin (usually netrw). The message means that netrw is not loaded (yet).
I added the following list to my init.vim
Please, take your time reading :h startup. To put it short, vimrc (or init.vim) is processed long before any plugin is loaded. You really should delay your command until VimEnter event. Kind of
if v:vim_did_enter
DoSomethingIfSourcedManually
else
autocmd VimEnter * ++once ++nested DoSomethingOnStartup
endif
Related
when I use this script in my .vimrc:
"Save and restore folds when a file is closed and re-opened
autocmd BufWinEnter ?* if(!empty(glob(expand("%:p")))) | silent loadview | endif
autocmd BufWritePost,BufLeave,WinLeave ?* if(!empty(glob(expand("%:p")))) | mkview | endif
It creates errors when I open the command line window via q: (which opens up all the previous commands that I typed):
How can I fix that, and make sure that this error does not occur?
Certain commands are not allowed in the command-line-window; :help E11 explains that.
To deal with this in your :autocmd, there are several options:
suppress any error by prepending :silent! to the :mkview command
surrounding the call with :try ... catch /^E11:/ to just selectively ignore this error, but report anything else
add a check for the command-line window in your :if condition; in recent Vim versions, you can use getcmdwintype(); it returns an empty String in other windows; for a check that also works with older Vim versions, see ingo#compat#window#IsCmdlineWindow() in my ingo-library plugin
I like to have Vim open a cheatsheet at startup. Adding this to _vimrc works nicely with MacVim:
:e *path-to-cheatsheet*
but on Windows, vim displays a message box at startup:
"~\Dropbox\vimfiles\myvim\vimcheat.txt"
"~\Dropbox\vimfiles\myvim\vimcheat.txt" [unix] 52L, 1735C
When the message box is dismissed, Vim completes startup and opens the cheatsheet. How do I get this to work cleanly with Windows Vim?
The ~/.vimrc is processed at the very beginning of :help initialization. You can use the VimEnter event to open the file after all the startup stuff is done:
autocmd VimEnter * edit path/to/cheatsheet
If you don't want to see the messages, use silent edit. If you don't care about errors (if the cheatsheet isn't there), use silent!.
I am recently moving from sublime 3 go to mvim (vim on the mac os) and am trying to get my Golang development environment to be as similar on vim to my sublime implementation as possible.
Within my sublime setup, it runs go build anytime I save the a Go file. This provides me instant feedback on if I have unused vars or other info go build provides.
I'm attempting to move to vim, and am wondering if I can have this functionality implemented there as well. I am using vim-go but have not found a setting to implement this.
In short I want to run :GoBuild upon the saving of a Go file while using vim / vim-go. Is this Possible and how do I do so?
yes, use vim autocommand to run :GoBuild:
You can specify commands to be executed automatically when reading or
writing a file, when entering or leaving a buffer or window, and when
exiting Vim. The usual place to put autocommands is in your .vimrc or
.exrc file.
Run the following command:
:autocmd BufWritePre *.go :GoBuild
Now each time you save your Go file with :w it will run :GoBuild too.
The event type is BufWritePre, which means the event will be checked just before you write *.go file.
BufWritePre starting to write the whole buffer to a file
BufWritePost after writing the whole buffer to a file
and:
When your .vimrc file is sourced twice, the autocommands will appear
twice. To avoid this, put this command in your .vimrc file, before
defining autocommands:
:autocmd! " Remove ALL autocommands for the current group.
If you don't want to remove all autocommands, you can instead use a
variable to ensure that Vim includes the autocommands only once:
:if !exists("autocommands_loaded")
: let autocommands_loaded = 1
: au ...
:endif
like this (put this at the end of your vim startup file):
:if !exists("autocommands_loaded")
: let autocommands_loaded = 1
: autocmd BufWritePost *.go :GoBuild
:endif
ref:
http://vimdoc.sourceforge.net/htmldoc/autocmd.html
http://learnvimscriptthehardway.stevelosh.com/chapters/12.html
Create ~/.vim/after/ftplugin/go.vim with:
autocmd BufWritePre *.go :GoBuild
The current gf command will open *.pdf files as ascii text. I want the pdf file opened with external tools (like okular, foxitreader, etc.). I tried to use autocmd to achieve it like this:
au BufReadCmd *.pdf silent !FoxitReader % & "open file under cursor with FoxitReader
au BufEnter *.pdf <Ctrl-O> "since we do not really open the file, go back to the previous buffer
However, the second autocmd failed to work as expected. I could not figure out a way to execute <Ctrl-o> command in a autocmd way.
Could anyone give me a hint on how to <Ctrl-O> in autocmd, or just directly suggest a better way to open pdf files with gf?
Thanks.
That's because what follows an autocmd is an ex command (the ones beginning
with a colon). To simulate the execution of a normal mode command, use the
:normal command. The problem is that you can't pass a <C-O> (and not
<Ctrl-O>) directly to :normal, it will be taken as literal characters (<,
then C, then r) which is not a very meaningful normal command. You have two
options:
1.Insert a literal ^O Character
Use controlvcontrolo to get one:
au BufEnter *.pdf normal! ^O
2.Use :execute to Build Your Command
This way you can get a more readable result with the escaped sequence:
au BufEnter *.pdf exe "normal! \<c-o>"
Anyway, this is not the most appropriate command. <C-O> just jumps to the
previous location in the jump list, so your buffer remains opened. I would do
something like:
au BufEnter *.pdf bdelete
Instead. Still I have another solution for you.
Create another command with a map, say gO. Then use your PDF reader
directly, or a utility like open if you're in MacOS X or Darwin (not sure if
other Unix systems have it, and how it's called). It's just like double clicking
the icon of the file passed as argument, so it will open your default PDF reader
or any other application configured to open any file by default, like images or
so.
:nnoremap gO :!open <cfile><CR>
This <cfile> will be expanded to the file under the cursor. So if you want to
open the file in Vim, use gf. If you want to open it with the default
application, use gO.
If you don't have this command or prefer a PDF-only solution, create a map to
your preferred command:
:nnoremap gO :!FoxitReader <cfile> &<CR>
If the default app is acceptable, then simply using :!open % in command mode works. You can always map this to a suitable leader combination in your vim config file etc.
If you want something that works with normal mode, then you could try something like the following (i use this too for opening HTML files), and modify to your own needs:
if has('win32') || has ('win64')
autocmd FileType html nmap <Leader>g :silent ! start firefox "%"<cr>
elseif has('mac')
autocmd FileType html nmap <Leader>g :!open "%"<cr><cr>
endif
According to the answer of this question, the :bd command should not quit Vim (gVim) when it is the last buffer remaining. Unfortunately, it does close gVim in my case. Did I understand something wrong about :bd?
I am also using a preconfigured vimrc file. Maybe a setting in there has that side affect, but I couldn’t find it.
Try doing the following:
:set eventignore=all | bd | set eventignore=
If this won't quit vim then you have some plugin that defines an autocommand that quits vim when no more buffers are present in the list, so after that try doing
verbose autocmd BufWinLeave,BufLeave,BufDelete,BufUnload,BufWipeout
This will show you all autocommands attached to given events (these are events that are executed when buffer is deleted) and where they were defined. Note that I do not have any autocommands attached to these events that are defined by plugins in standart vim distribution.
Update: I do not see anything bad in your output. You may also try
verbose autocmd BufNew,BufAdd,BufCreate,BufEnter,BufWinEnter
(because when you leave last buffer new empty one is created). If this does not show anything suspicious, start ignoring event types: if you are on linux try the following script:
for event in BufWinLeave BufLeave BufDelete BufUnload BufWipeout BufNew BufAdd BufCreate BufEnter BufWinEnter
do
event=$event vim file -c "set eventignore=$event | bd"
done
This script should iterate until you find event name that causes trouble. After this you can use execute "verbose autocmd" $event in vim to narrow number of plugins that should be checked. After you got list of autocmd groups (augroup names are shown just before event name in your output: railsPluginDetect is one of such groups), delete events in them (augroup {GroupName} | execute 'autocmd!' | augroup END) and find out which plugin to claim.
Alternatively, you can use debugger:
debug bd
, then s<CR>n<CR><CR><CR>... until vim quits; don't forget to remember what vim have shown above > prompt before quiting.