I have an auto command triggered off BufEnter in my .vimrc to cd into the current buffer directory (very useful)
au BufEnter * execute ":lcd " . expand("%:p:h")
The problem is this fails on FTP files (as you might expect). The real problem is the error message telling me it has failed. Is there any way to suppress the error message, or alternatively "cd" into the current directory for FTP files as well (to make opening other files in the directory easier).
Just making the error message go away would be very helpful though! I've tried various experiments with the :silent command, but either it's not working for this command, or I didn't put it in the correct place.
Did you try:
au BufEnter * execute ":silent! lcd " . expand("%:p:h")
:silent! is supposed to skip errors as well as messages.
As a side note, also have a look at :h 'autochdir' which does something similar to your autocommand. (However see :h netrw-incompatible for caveats.)
Related
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
I'd like to open CtrlP if I am opening a directory with vim, but not a file. I like to have it automatically open in I just open a directory for convenience. However, it is slightly inconvenient if I know exactly which file I want to open because of the added loading time.
Currently I just have this in my .vimrc:
autocmd vimenter * CtrlP
Thanks in advance for any responses!
You can write a function to test the args to see if a single directory was passed in and if it was, execute CtrlP. Here is a very rudimentary solution:
function! MaybeCtrlP()
if argc() == 1 && isdirectory(argv()[0])
" Uncomment this to remove the Netrw buffer (optional)
" execute "bdelete"
execute "CtrlP"
endif
endfunction
autocmd VimEnter * :call MaybeCtrlP()
In .bash_profile, create an alias:
alias vimCtrlP="vim +CtrlP"
Then every time you need this, use vimCtrlP as you would issue vim in shell, followed by the directory.
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.
I have the following command run as a vim plugin under ~/.vim/plugin/autohighlight.vim
:autocmd CursorMoved * exe printf('match IncSearch /\<%s\>/', expand('<cword>'))
The thing is, it throws a bunch of errors anywhere except when I'm editing a file. (file Explorer, other windows)
Is there a way to tell the script to only take effect when a file is edited and not anywhere else in VIM?
You can try this one:
autocmd CursorMoved * :if filewritable(#%)==1 |
\ call matchadd('IncSearch', '\V\<'.escape(expand('<cword>').'\>', '\'), 10, 1) |
\endif
It will do highlighting only if current buffer name is a writable file (not directory). It will fail if you are editing something which uses BufWriteCmd to perform saving (for example, if you are editing file inside a zip archive).
By the way, can you provide these errors? I was able to get an error when I used :e ., but it was not related to the fact that you are observing a directory, it appeared just because you forgot to do escaping. If you have written escape(expand('<cword>'), '\/') instead of expand('<cword>') then such error would not appear.