Huge files take forever to load and work with in vim, due to syntax-highlighting.
I'm looking for a way to limit size of highlighted files, such that files larger than (say) 10MB will be colorless.
Adding the following line to _vimrc does the trick, with a bonus: it handles gzipped files, too (which is a common case with huge files):
autocmd BufWinEnter * if line2byte(line("$") + 1) > 1000000 | syntax clear | endif
Add to your .vimrc:
autocmd BufReadPre * if getfsize(expand("%")) > 10000000 | syntax off | endif
Note that this disables syntax highlighting in ALL buffers; syntax is a global vim thing and cannot be restricted to a single buffer.
I haven't tried it myself, but the LargeFile plugin seems to be exactly to address the kind of stuff you're looking for.
vim -u NONE <filename>
This will skip all initializations from configuration files.
Use uppercase U when running gvim.
"-i NONE" does only exclude viminfo from being loaded. If you defined syntax hilighting in there, that would help too.
vim -c 'syntax off' filename.ext
Related
I want these commands run on every filetype except my vimwiki file (.wiki and .md)
Here is how I'm trying to do it:
let ftToIgnore = ['wiki', 'md']
autocmd BufWinEnter * if index(ftToIgnore, &ft) < 0 | syntax on
autocmd BufWinEnter * if index(ftToIgnore, &ft) < 0 | colorscheme minimalist
It is not working. It is running these commands on every single filetype, including wiki/md.
How can I fix this?
There are several things we need to clear.
First, I think some commands are inherently global even though you have only run it for specific filetypes, for example, the above colorscheme command is a global command, you can not make it work only for one buffer.
To verify, you can open several files of different types, if some file does not match your ignore type, colorscheme command will run. Then for all the files, colorscheme will be set to that theme you choose, even though you haven't specified colorscheme for the ignored file types.
Second, you can not use &ft to check the file type of a file when reading it, at that time, file type detection is being conducted, and the type of file haven't been determined. You can use file suffix to check a file's type like this: expand('%:p:e') (this will get the suffix of a file).
In summary, you are doing two things wrong: (1) use a inherently global options or commands and expect it to work only for a certain file type (2) use &ft to decide a file's type during its opening.
If you use some options that can be local to a buffer and change the way you detect a file's type, you will find that the command can be local to that file. For example, use the following toy.vim config:
let suffix_to_ignore = ['md', ]
autocmd BufWinEnter * if index(suffix_to_ignore, expand("%:p:e")) < 0 | setlocal tabstop=4 | endif
Activate vim with vim -u toy.vim. Then edit a vim file, :e toy.vim, set tabstop? shows that tabstop is set to 4. Open a markdown file, :e test.md, set tabstop? shows that tabstop is still 8. So the command is indeed only run for other filetypes other than Markdown.
References
Does “set” command affect only the active buffer?
is per-buffer colorscheme possible?
When diffing 2 files in VIM, I prefer the lines to be wrapped. However, vimdiff sets wrap to off by default.
Is there a way to set line wrap automatically for every diff?
I use the following:
autocmd FilterWritePre * if &diff | setlocal wrap< | endif
FilterWritePre is triggered immediately before a generated diff is written to the buffer, and setlocal wrap< copies the global value of wrap. Of course it's also possible to simply force setlocal wrap.
You can put the following in your vimrc.
au VimEnter * if &diff | execute 'windo set wrap' | endif
When vim is already started, the commands to start a diff and a wrap are, on each of the split window files:
:diffthis
:set wrap
However, the diff+wrap is improperly displayed:
If you have a long line on one file, and a short or missing line on the other, then the long line will occupy, say, 2 lines on the first side, by the short or missing line will only occupy 1 line on the second side.
This results in a vertical shift of the 2 files. Sure, the colors help to visually compensate this shift. But over several lines of diff, the shift may be higher than the height of the window, making diff unreadable.
So the question is not fully solved...
Please advise.
You can run this
vimdiff -c 'set wrap' -c 'wincmd w' -c 'set wrap' file1 file2
I had to solve this question for a demo where I wanted vimdiff to wrap only when launched from a certain terminal.
I finally resorted on the crude:
alias vimdiff='vimdiff +"windo set wrap"'
vimdiff file.orig file
If you have more files, and you don't want to make this permanent in your vimrc
vimdiff -c 'windo set wrap' file1 file2 file3 [file4]
or just windo set wrap once vim is open
Starting from VIM 8.2.2490 there is a followwrap option for diffopt. You can set it with :set diffopt+=followwrap.
I find that the :set diffopt+=followwrap setting only affects the second pane, for reasons unknown to me. I have to :setlocal wrap separately to get the first pane to also wrap, and that setting only operates if the diffopt setting is also in play. Bizarre, but at least it works. The trick now will be to put that inside some conditional that checks the vim version, so I can have one .vimrc that works across platforms.
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
I have a ~/.vimrc file that vim doesn't seem to be reading.
There is a file at /etc/vimrc, and it looks like it is using that one.
My understanding is that the one in the home directory should override this one, shouldn't it?
Update
cat vim_strace | grep .vimrc
stat64("/etc/vimrc", {st_mode=S_IFREG|0644, st_size=1438, ...}) = 0
open("/etc/vimrc", O_RDONLY|O_LARGEFILE) = 3
stat64("/etc/vimrc", {st_mode=S_IFREG|0644, st_size=1438, ...}) = 0
stat64("/root/.vimrc", {st_mode=S_IFREG|0644, st_size=35, ...}) = 0
open("/root/.vimrc", O_RDONLY|O_LARGEFILE) = 3
stat64("/root/.vimrc", {st_mode=S_IFREG|0644, st_size=35, ...}) = 0
Once you've loaded vim, :scriptnames will tell you exactly what Vim read.
For me, it starts like this:
1: /Applications/MacVim.app/Contents/Resources/vim/vimrc
2: ~/.vimrc
3: /Applications/MacVim.app/Contents/Resources/vim/runtime/syntax/syntax.vim
4: /Applications/MacVim.app/Contents/Resources/vim/runtime/syntax/synload.vim
5: /Applications/MacVim.app/Contents/Resources/vim/runtime/syntax/syncolor.vim
IF you want to check where a particular setting is being set, use "verbose set". For example, :verbose set background tells me:
background=light
Last set from ~/.vimrc
so I know that my setting in ~/.vimrc is being read, and that none of the later files is clobbering it.
if you're on linux and want to know if vim is accessing your ~/.vimrc on startup you can launch it with strace:
strace -o vim_strace vim
then quit vim.
Open the vim_strace file and search for "vimrc" in the file. you should find a line like that
stat64("/home/youruser/.vimrc", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
which mean that at least vim sees the file.
If anyone happen upon this issue while using neovim you should know (before you start pulling off your hair) that the .vimrc file is loaded from ~/.config/nvim/init.vim.
mkdir -p ~/.config/nvim; ln -s ~/.vimrc ~/.config/nvim/init.vim
I had this problem and just added the following to the file ~/.bash_profile:
alias vim="vim -S ~/.vimrc"
In case anyone else runs across this issue, and like me realizes .vimrc wasn't read because of sudo, try using sudo -E. It retains your environment for the command, and $HOME will point to your own home dir. Note this may not work in environments where /home is mounted with rootsquash.
Just to add on hellvinz's instruction.
After you have made vim_strace file.
cat vim_strace | grep .vimrc
makes life bit easy :)
Stumbled on this post and non of the suggestions worked for me. Some useful things not mentioned here:
vim --version should give you some useful info including the startup files. (Mine listed "virc" in several places (not vimrc)
If your vim isn't really vim then perhaps it is looking for ~/.exrc instead of .vimrc (Mine looks for some system vircs, then some users vircs and then $HOME/.exrc)
If your file (whichever one it is) has DOS line endings it may cause errors
... so even though I've got a real vim, it's looking for "virc"
On OSX 10.8.0 the location of the vimrc file is: /usr/share/vim/vimrc
I just add my changes to the bottom of the file.
Of course this has the effect of making the changes for all users. For the life of me I can't seem to figure out how to get it to read ~/.vimrc. This was never an issue for me on 10.6.x
Anyway this is a quick fix even it is a bit dirty.
Cheers
use file /etc/vim/vimrc.local in Ubuntu
Check if $VIMINIT has been set. It may prevent reading your ~/.vimrc. See :help VIMINIT:
c. Four places are searched for initializations. The first that exists
is used, the others are ignored. [...]
- The environment variable VIMINIT [...]
For me unsetting VIMINIT did the trick, my ~/.vimrc is now read.
After checking scriptnames and verbose as suggested above, I noticed that my setting was indeed being loaded, but being overridden by another plugin, thus giving the impression that it was not reading/loading the .vimrc.
If this happens to you and you want to override a specific setting from a plugin, without completely eliminating all the other good things that come from that plugin, you can create a config file to load after the plugin is loaded, by creating a file in ~/.vim/after/<path>/<plugin_name>. For reference, see this other question.
/etc/vim/vimrc is now overwritten by defaults.vim unless there is a ~/.vimrc, apparently.
https://github.com/vim/vim/issues/2042
I had the same problem with vim 8.1.3741 on Kubuntu 20.04
It seems the problem was that the ~$/.vimrc file was starting with a long comment starting with " and went over 2 lines (autobreak) The vim_strace showed input 133 and wrote the comment out but not the command under it. Removing the comment worked. Thanks for info.
For me, the mistake was I had the configuration set at ~/.vim/.vimrc.
After reading some documentation, I found that right path is ~/.vim/vimrc.
Changing the file did the trick.
TL;DR check that you don't have any inline comments in your .vimrc
After all of the helpful answers under this question I was still stuck. My ~/vimrc
set mouse-=a
set tabstop=4 " Indents will have a width of 4
set shiftwidth=4
set softtabstop=4 " Sets the number of columns for a TAB
set expandtab " Expand TABs to spaces
syntax on
set paste
" set compatible
set t_ti= t_te= "stop ^z clearing the screen
" remember line
if has("autocmd")
au BufReadPost * if line("'\"") > 1 && line("'\"") <= line("$") | exe "normal! g'\"" | endif
endif
" unless gitcommit
autocmd FileType gitcommit call setpos('.', [0, 1, 1, 0])
was located by vim and strace showed that it was read. Turns out that vim.basic on my system seems to ignore the entire line if it contains a comment. (So inline comments disable settings on the same line.)
I moved the "Expand TABs to spaces" comment to the previous line and instantly expandtab showed up the next time I ran vim -c :set
I have the following in my .vimrc
syntax on
filetype plugin indent on # Thanks to Jeremy
I run
vim ~/.vimrc
I get the right syntax highlighting.
I source many files in my .vimrc. My .vimrc is a like a roadmap for me where I navigate by
CTRL-W f
The problem occurs when I navigate to a file which I have sourced: no colors.
All my sourced files contain the word Vim in their PATHs.
It may be possible to use this fact in solving the problem.
How can you provide a syntax highlighting automatically for the sourced files?
Do the files in question end in ".vim"? If not, then vim's filetype detection may not be able to determine that these files contain vim-script. You can either rename the files so that they end in .vim, or add an autocommand to set the filetype appropriately.
To do the latter, you can add something like this to your .vimrc:
au! BufNewFile,BufRead PATTERN set filetype=vim
replacing "PATTERN" with a file pattern that will match the files in question.
EDIT:
See :help autocmd-patterns for how the patterns work:
The file pattern {pat} is tested for a match against the file name in one of
two ways:
1. When there is no '/' in the pattern, Vim checks for a match against only
the tail part of the file name (without its leading directory path).
2. When there is a '/' in the pattern, Vim checks for a match against the
both short file name (as you typed it) and the full file name (after
expanding it to a full path and resolving symbolic links).
In particular, note this example:
Note: To match part of a path, but not from the root directory, use a '*' as
the first character. Example: >
:autocmd BufRead */doc/*.txt set tw=78
This autocommand will for example be executed for "/tmp/doc/xx.txt" and
"/usr/home/piet/doc/yy.txt". The number of directories does not matter here.
In your case you probably want something like:
au! BufNewFile,BufRead */Vim/* set filetype=vim
To make vi consider my jQuery (.jq) files are actually javascript (.js) I did: -
Create and/or or edit your vimrc file ...
e#dev3:~$ vi ~/.vimrc
Add the following text (press i to insert) ...
if has("syntax")
syntax on
filetype on
au BufNewFile,BufRead *.jq set filetype=javascript
endif
Save the vimrc file ...
[esc]:wq[enter]
Further, to find supported filetypes look in filetype.vim ...
e#dev3:~$ sudo locate filetype.vim
/usr/share/vim/vim72/filetype.vim
e#dev3:~$ sudo grep "\.js[, ]" `locate filetype.vim`
au BufNewFile,BufRead *.js,*.javascript,*.es,*.jsx setf javascript
... the filetype is the setf arg ...
e#dev3:~$ sudo grep "\.js[, ]" `locate filetype.vim` | cut -d " " -f 4
javascript
Have fun.
What is the extension of the files you source? The extension is the usual way for Vim to detect what syntax highlighting it neds to use, and for source-able files (vimscript) it should be .vim. It sounds like that's not the case, if you only see the problem with the sourced files, and not with any others.
One obvious question is there's no line saying "syntax off" in the files you're sourcing?
It could be:
the "filetype" option
the filetype might not be auto-detected by vim
filetype on sorts the first, and the second is fixable with autocmds based on the file extensions.