I run a command every time a save a file which, among other things, lints the current file. Vim does two annoying things which I wanted to avoid:
It asks me to press enter after the command was executed.
It notifies me that the current file has been modified outside of Vim.
How to get rid of this? I just want this to behave unobtrusively as ALE linters. This is my code:
autocmd BufWritePost *.prisma :execute '!npx prisma format'
#romainl's comment gave me an idea on how to do it:
autocmd BufWritePre *.prisma silent write | silent :execute '!npx prisma format' | edit! %
It's not the cleanest way to do it but it works. silent hides the command output and edit! forces Vim to open the modified file.
Related
I have the following line in my .vimrc to automatically beautify js files after I save them:
autocmd BufWritePost *.js :call JsBeautify()
I want this 99% of the time, but sometimes I just want to write without having this function called. Is there an easy way to do that?
I guess you're looking for :noa.
Usage:
:noa w
Excerpt from help:
:noautocmd :noa
To disable autocommands for just one command use the ":noautocmd" command
modifier. This will set 'eventignore' to "all" for the duration of the
following command. Example:
:noautocmd w fname.gz
This will write the file without triggering the autocommands defined by
the
gzip plugin.
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
Here I got simple task for skilled vimmers. I need to reformat my css file. There are commands to do this:
%s/}/&\r/g
%s/ / /g
retab!
echo "You done did it!"
But I don't want to type these commands every time I need to format my css file (I get it after convert less file by WinLess program). Now I put these commands into cssformat.vim file, and put this file into vim runtime folder. In my vimrc I set:
autocmd Filetype css nmap :so $VIM/vim73/cssformat.vim
It's works, of course. But I wonder how can I do this task better? In the begginig I want to put these commands in my vimrc (to create a simple function), but I don't know how to do this correctly.
p.s. Sorry for my bad English.
Just put the commands from your script into a function:
function! ReformatCss()
" Place your commands here.
endfunction
And move the stuff into your .vimrc. Now you can invoke this via :call ReformatCss().
To top it off and make it even simpler, define your own command:
command! ReformatCss call ReformatCss()
Now you can invoke via :ReformatCss. Voila!
You can learn more at :help usr_40.txt and :help :command. For example, if you only need this for CSS files, you can turn this into a buffer-local command through command -buffer and moving the function and command definition to ~/.vim/ftplugin/css_reformat.vim
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.