This is in reference to the accepted answer here written by Paul Biggar:
After considering all these options for some time, I have settled with the following solution.
Set vim to write continuously as I type.
Run a script in the background to build continuously, refreshing the pdf as it goes. latexmk is nearly good enough, except that it builds in place, which gets reloaded at a bad time in okular (my viewer).
The script is available at https://github.com/pbiggar/texbuild.
Use rubber-info to get the errors and warnings from the log file. The script above saves the log file in t.log. In vim:
autocmd FileType tex set makeprg=rubber-info\ t.log
autocmd FileType tex set errorformat=%f:%l:\ %m
I want to execute his github script in order to "build [LaTeX files] continuously, refreshing the pdf as it goes." Given that he doesn't exactly offer instructions how to run it, I assume this is a rather trivial procedure. However, I'm quite new at vim and know very little about programming/github in general, so I really have no clue how to start.
I've searched high and low, and have made zero progress. I'm not sure if the code is supposed to be compiled in python, then run as a script, or anything similar. I appreciate your help!
EDIT: As per the comments discussion, I've successfully made the script executable. But I still don't know how to run it..?
The
#!/usr/bin/env python
at the top of the script states, as well as absence of import vim in the body clearly states that it should be run from the shell (or from vim) using
chmod +x /path/to/texbuild # Needed only once
/path/to/texbuild {script-args}
. Further exploration reveals that it expects to have one tex file as its first and only argument (the only place where sys.argv is mentioned is line 48) hence it is likely that you should use the following to run it:
augroup AutorunTexbuild
autocmd!
autocmd FileType tex :if !exists('b:runtexbuild') | call system('/path/to/texbuild '.shellescape(#%)) | let b:runtexbuild=1 | endif
autocmd VimLeave * :call system('killall -TERM texbuild')
augroup END
. That assumes that you edit tex files only in one vim instance at a time. It looks like author expected you to run that script manually.
Related
I want to install this closetag.vim script:
http://vim.sourceforge.net/scripts/script.php?script_id=13
It says
place this file in your standard vim scripts directory and source it
while editing the file you wish to close tags in.
And this is shown as an example:
:let g:closetag_html_style=1
:source ~/.vim/scripts/closetag.vim
1) What is my standard vim scripts directory on W7?
I have neither .vim nor scripts folder on my system. And if I have\am expected to create one (or ones) where should it (they) be placed? %ProgramFiles%\Vim\vim80 or %ProgramFiles%\Vim\vimfiles or maybe somewhere else?
1.1) Also, this might be a silly thing to ask about, but why do I keep seeing that tilde in path almost every time I read about Vim. Does it mean that Vim is used primarily by Mac/Linux people? Why is that?
2) What does it mean to source the script? Run a command like this let g:closetag_html_style=1 in command mode in Vim?
Btw what does style=1 mean here?
And if I want it to work by default for all html\xhtml\xml files, what do I do? Put this command to _vimrc file?
Thank you so much!
You could find the answers to all your questions just by reading the plugin description carefully. Unfortunately, it is both poorly written and factually incorrect.
What is my standard vim scripts directory on W7?
On Windows, you are supposed to put custom and third-party scripts in various places under:
C:\Users\username\vimfiles\
But that's not what the author means by "standard vim scripts directory". What he is referring to is this:
C:\Users\username\vimfiles\scripts\
which is not standard at all.
Also, this might be a silly thing to ask about, but why do I keep seeing that tilde in path almost every time I read about Vim. Does it mean that Vim is used primarily by Mac/Linux people? Why is that?
Yes, Vim is primarily used by UNIX-like systems users. Because of history.
What does it mean to source the script? Run a command like this let g:closetag_html_style=1 in command mode in Vim?
No. Read your question again.
Btw what does style=1 mean here?
Nothing.
But :let g:closetag_html_style=1 means "set the g:closetag_html_style option to true".
And if I want it to work by default for all html\xhtml\xml files, what do I do? Put this command to _vimrc file?
No. This is explained on the plugin's page:
For greater convenience, load this script in an autocommand:
:au Filetype html,xml,xsl source ~/.vim/scripts/closetag.vim
Which is wrong on many levels.
Here is what you actually have to do to use that script:
Save the closetag.vim script to the following location:
C:\Users\username\vimfiles\scripts\closetag.vim
Create vimfiles\ and/or vimfiles\scripts\ if they don't exist.
Add the lines below to C:\Users\username\_vimrc:
augroup closetag
autocmd!
autocmd Filetype html,xhtml,xml,xsl runtime scripts/closetag.vim
augroup END
let g:closetag_html_style = 1
Reference:
:help startup
:help :source
:help :runtime
:help :let
:help autocommand
As part of learning Haskell, for fun I'm attempting to use Raspberry PI. Having encountered a myriad of issues installing ghci on the PI I've resolved to using just ghc.
So to create, compile & run a new Haskell file :
vi first.hs
i
main = putStrLn "First"
Esc
:w
:q
ghc -o first first.hs
./first
Output is : "First"
I would like to automate the commands :
Esc
:w
:q
ghc -o first first.hs
./first
Can these be added as new command from within vi / vim, something like :
:mycustomcommands
And run from within the vi / vim editor ?
Maybe you could try adding something like this to your vimrc:
function! ExecuteHS()
w
!ghc -o first %
!./first
endfunction
And to use this function you just have to call it like that :call ExecuteHS(). Vim will be put on background during the execution of your file and will then come back on foreground at the end of the execution.
As a bonus you can add the folowing line to your vimrc
nnoremap <key> :call ExecuteHS()<CR>
Replacing <key> with your prefered key combination <Leader>e for example. This way you'll simply have to hit ,e (if you didn't changed your leader key) in normal mode to call the function.
That's probably not the cleanest way to do it but it should work for what you want.
Absolutely in vim, though not necessarily in other vi flavors. See this tutorial on defining custom commands. Put the custom command in your vimrc and it will always be available as :Customcmd or whatever you call it. For one-button access, you can use :remap to assign a hotkey to your custom command or the sequence of built-in commands you want to run. This is a tutorial on keymappings that will give you more information.
I second #statox's referral to https://vi.stackexchange.com :)
I use vim-haskell, which includes a couple nice things. In particular, it includes a file for setting up cabal-install as the compiler, which is a very nice way of working. Dump this in ~/.vim/compiler/cabal-build.vim:
CompilerSet makeprg=cabal\ build
CompilerSet errorformat=
\%W%f:%l:%c:\ Warning:%m,
\%W%f:%l:%c:\ Warning:,
\%E%f:%l:%c:%m,
\%E%f:%l:%c:,
\%C\ \ %#%m,
\%-G%.%#,
\%-G%.%#
And this in ~/.vim/ftplugin/haskell.vim:
compiler cabal-build
(The argument to compiler should match the name of the file you put in ~/.vim/compiler.) Then you can run :make in vim and it will save any changed buffers (assuming autowrite is set) and build your project. When there are errors, it will populate the quick-fix list, which lets you jump to the specific file and line numbers of each error or warning with a key. Read more about this feature with :help quickfix. Once everything is working, you can :!cabal run to run it.
I run vim with no file on the command-line, so that it shows the scratch buffer. When I then run
:e foo
to edit file 'foo', there is a BufUnload event triggered for file 'foo'. Here is a test vim command that I use to demonstrate the issue:
autocmd BufUnload * echom "Unloaded " . expand("<afile>")
Does anyone know what is causing this, and if there is a way to detect this situation and ignore it?
I can reproduce this with the latest Vim 7.4a.39. I guess this has to do with the fact that Vim reuses the initial scratch buffer number (1) for the first :edited file. Please report this problem to the vim_dev mailing list.
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
When I open some bash script files with vim it sometimes identifies them as conf files, that's okay, I can just correct that by setting the filetype to sh with :setf sh.
That great, except I've noticed that this doesn't fix things entirely:
Notice that shopt is properly highlighted on the left, but not on the right, where I manually set the filetype to sh.
This means that when a file is identified as bash or sh by vim, it sets the filetype to sh but then does some extra steps that I'm not doing when I set the filetype manually.
Any one know what that might be, and how I could fix it?
vim already recognizes many file types by default. Most of them work by file extensions, but in a case like this, vim will also analyze the content of the file to guess the correct type.
vim sets the filetype for specific file names like .bashrc, .tcshrc, etc. automatically. But a file with a .sh extension will be recognized as either csh, ksh or bash script. To determine what kind of script this is exactly, vim reads the first line of the file to look at the #! line.
If the first line contains the word bash, the file is identified as a bash script. Usually you see #!/bin/bash if the script is meant to be executed directly, for some other shell configuration file you should use the file extensions .bash.
The help in vim explains this as well at :help ft-bash-syntax. You can also use let g:is_bash=1 in your .vimrc to make bash syntax highlighting the default for all files with filetype=sh. If you want to look at the details, this is implemented in $VIMRUNTIME/filetype.vim.
It turns out that syntax/sh.vim includes specific highlighting for Korn, Bash and sh, you just have to tell it which you're using. This is done with b:is_kornshell, b:is_bash and b:is_sh respectively.
Depending on the situation I figure I'll use the following:
ftdetect/bash.vim:
au BufRead,BufNewFile *bash* let g:is_bash=1
au BufRead,BufNewFile *bash* setf sh
Modeline:
# vim:let g:is_bash=1:set filetype=sh:
Key Mapping
nmap <silent> <leader>b :let g:is_bash=1<cr> :setf sh<cr>
Similar to Peter Coulton's solution and documented as well as an alternative in the section "new-filetype" of the "filetype" Vim help the ~/.vim/filetype.vim file could contain the following code:
if exists("did_load_filetypes")
finish
endif
augroup filetypedetect
au! BufRead,BufNewFile *bash* let b:is_bash = 1 | setfiletype sh
augroup END
This approach has the following implications:
There is one ~/.vim/filetype.vim file instead of one for each file type under the ~/.vim/ftdetect directory.
The b:is_bash variable is set local to the buffer as opposed to global by referring to it as g:is_bash.
Try viewing the effective syntax setting
:windo echo b:current_syntax
(I kind of expect the first window to say bash, and the second to say sh...?)
Also try mucking with the synatx synchronisation:
:windo syn sync fromstart
:windo syn sync minlines=300
In general
:he syn-sync
for more information
PS.
A long shot, but some other highlighting might be interfering:
:windo se #/=''
:match none
:2match none
:3match none