Currently running:
VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Sep 1 2012 18:08:47)
MacOS X (unix) version
Included patches: 1-646
Compiled by Bjorn Winckler <bjorn.winckler#gmail.com>
I have these lines in my .vimrc
if has("gui_macvim")
source ~/.vim/vimrc/mygfuncs.vim
endif
In the mygfuncs file are some functions that set the guitablabel and guitabtooltip based on two custom functions. The file is being sourced (because the functions are defined), but the lines that set those variables using those functions aren't working:
set guitabtooltip=%{GuiTabToolTip()}
set guitablabel=%{GuiTabLabel()}
At this point, the variables are set properly, because if I
:set guitabtooltip
Vim responds with
guitabtooltip=%{GuiTabToolTip()}
But it isn't actually being applied.
But if I then :so ~/.vimrc, the tab label and tooltips are applied.
What is going on here?
I believe the only time it will be properly executed is when you have the code block:
if has("gui_macvim")
source ~/.vim/vimrc/mygfuncs.vim
endif
... in a self contained ~/.gvimrc file.
Related
In vim, when I am in insert mode and press the arrow keys I get letters instead:
As you can see, the arrow keys, when pressed, insert a line above the current cursor position including either A, B, C or D.
How do I stop this?
Things I've tried
I have set nocompatible in my ~/.vimrc (vimrc pastebin), I am using pathogen and here is my ~/.vim/bundle directory:
YouCompleteMe/
emmet-vim/
nerdtree/
node/
vim-airline/
vim-markdown/
The problem only started recently, but I can't think of what caused it.
I've done :set term=builtin_ansi, and this fixes the problem but removes all my colors.
$ vim --version
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Aug 29 2016 12:51:13)
MacOS X (unix) version
Included patches: 1-2290
Compiled by Homebrew
Huge version without GUI. Features included (+) or not (-):
...
See http://pastebin.com/5z1HbpqW for the whole output.
$ echo $TERM
xterm-256color
and in vim:
:set compatible?
nocompatible
:set term?
term=xterm-256color
Use this:
:set term=builtin_ansi
Source: http://vim.wikia.com/wiki/Fix_broken_arrow_key_navigation_in_insert_mode
This question already has answers here:
Enabling markdown highlighting in Vim
(5 answers)
Closed 8 years ago.
When I edit README.md containing Markdown code in Vim and execute :set filetype? command, I see filetype=markdown. The Markdown syntax is highlighted correctly.
But when I edit foo.md containing Markdown code in Vim and execute :set filetype? command, I see filetype=modula2. The Markdown syntax is not highlighted correctly.
What should I add to my ~/.vimrc to make Vim understand that foo.md or any file with extension name as .md is a markdown file and not modula2 file?
Cause of the issue
To understand which script was setting this filetype, I executed the following command after editing foo.md.
:verbose set filetype?
I found the following output.
filetype=modula2
Last set from /usr/share/vim/vim74/filetype.vim
In /usr/share/vim/vim74/filetype.vim, I found the following lines.
au BufNewFile,BufRead *.markdown,*.mdown,*.mkd,*.mkdn,*.mdwn,README.md setf markdown
au BufNewFile,BufRead *.m2,*.DEF,*.MOD,*.md,*.mi setf modula2
These lines show that when README.md is edited, the filetype is set to markdown but on editing any other file with extension name as .md, the filetype is set to modula2. In other words, *.md files are recognized as Modula-2 source code but an exception is made for README.md for it to be recognized as Markdown code, perhaps due to the growing popularity of README.md files on GitHub.
Solution
Add the following statement to ~/.vimrc to set filetype=markdown for all .md files.
autocmd BufNewFile,BufRead *.md set filetype=markdown
This statement says that when starting to edit a new file that doesn't exist or when starting to edit a new buffer, after reading the file into the buffer, if the file matches the pattern *.md then set filetype=markdown.
Update
In the updated version of Vim that I have now, I find that this issue no longer exists.
$ vim --version | head -n 2
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Mar 31 2015 23:36:07)
Included patches: 1-488, 576
$ grep -E "markdown|modula2" /usr/share/vim/vim74/filetype.vim
au BufNewFile,BufRead *.markdown,*.mdown,*.mkd,*.mkdn,*.mdwn,*.md setf markdown
au BufNewFile,BufRead *.m2,*.DEF,*.MOD,*.mi setf modula2
The patch at ftp://ftp.vim.org/pub/vim/patches/7.4/7.4.860 seems to have made this change. However, I am a little confused about how these changes that seem to be available in patch 860 is available in my version of Vim which includes patches 1-448, 576 only.
More complete answer with Markdown flavour
The other answer is correct, but incomplete. For this to equally work with the Save As… :sav command, one needs to extend the autocommand with BufFilePre:
autocmd BufNewFile,BufFilePre,BufRead *.md set filetype=markdown
It might also be interesting to specify a Markdown flavour, like Pandoc:
autocmd BufNewFile,BufFilePre,BufRead *.md set filetype=markdown.pandoc
Note that Vim currently allows specifying only one flavour though.
Here is my .vimrc
1 syntax on
2 set ts=4
3 set number
4 set smartindent
5 set shiftwidth=4
However, I tried to edit HelloWorld.java and HelloWorld.c. Both have pure regular black font. No any highlighting!
I also tried :syntax on after the vim is open, but no luck.
\>vim -version
VIM - Vi IMproved 7.3 (2010 Aug 15)
\>cat /etc/*-release
openSUSE 11.4 (x86_64)
VERSION = 11.4
CODENAME = Celadon
When you edit the file, are you using
vim filename
This can matter. In some server configurations, if you do vi filename you get vim, but it's a very stripped down version of vim that is very much like the original vi (which does not, among other things, do syntax coloring). On a system configured in this way, if you instead type vim filename, you get the full featured vim.
I just worked through this with a person who was on a server that had the vim-minimal package installed as well as another vim package. I suspect (but did not verify that) the vim-minimal package installed its executable as /bin/vi.
The difference was very clear when you looked at the actual files (i.e. ls -l /bin/vi vs ls -l /usr/bin/vim)--one was about ten times the size. Both of them were actually vim, same version number and everything, but the /bin/vi one was compiled with very few features enabled.
To make it even more confusing:
vi existing.pl
opened the .pl file, gave no syntax coloring
vi [enter]
gave the vim splash screen, and from there
:e existing.pl
opened the file with syntax coloring on.
A comment from Jan Wilamowski suggests checking by doing:
vi --version
If that shows that the syntax feature was not compiled in, try
vim --version
and see if it is compiled in there.
You'll need to install the vim-data package on openSUSE for vim syntax colouring to work.
Sounds strange, I know that this is not pulled in by default with the vim package but AFAIK it's for people who want to create tiny base installs.
Package vim-data contains the runtime files.
Also make sure your remote environment has an appropriate TERM variable set TERM=screen-256color, TERM=xterm, TERM=xterm-256color should all work just fine with ssh and ssh with screen/tmux.
If all above have been done and you see some underlines and bold instead of actual colors... this might work for you:
export TERM=xterm-color
in your .vimrc, I don't see filetype setting. you could try to add:
filetype plugin indent on
to your vimrc.
if you don't have set nocp, add this line too.
if you read :h filetype
:filetype on
Each time a new or existing file is edited, Vim will try to recognize the type
of the file and set the 'filetype' option. This will trigger the FileType
event, which can be used to set the syntax highlighting, set options, etc.
For some strange reason on MacOS, 'syntax on' must be the first line in your .vimrc file. The line appears to be ignored if placed elsewhere in the file.
One item not mentioned is :set syntax=<type>, e.g. :set syntax=markdown.
This has been successful in instances where other techniques above were not.
Whenever I work with multiple buffers, there is always one empty. I would like to not have that if I open a file with vim from the command line (i.e. I don't want to create a new file, or choose to create a new file by naming it first and starting vim with that name). How can I do this?
Edit:
I'm launching gvim the following way:
I have an alias in my bashrc: alias g="gvim --remote-silent"
I open files from the command line with: g name-of-file
At this point (if I didn't already have an instance of gvim open), I have two buffers:
Edit2:
Platform is Linux Mint, version is: VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Mar 24 2011 07:07:39).
I updated my NERDTree plugin as David suggested, but it didn't help. Other plugins I use: Pathogen, a, doxygentoolkit, nerdtree, snipmate, vim-rails,
ack_plugin, easymotion, protobuf, sparkup, yankring,
bufexplorer, matchit, rainbow, surround,
clang_complete, nerdcommenter, repeat
I don't have your problem on
linux, gvim - Vi IMproved 7.3 (2010 Aug 15, compiled Mar 24 2011 07:07:34) Included patches: 1-35
windows gvim - Vi IMproved 7.2 (2008 Aug 9, compiled Aug 9 2008 18:46:22) MS-Windows 32-bit GUI version with OLE support
You are probably looking at a bug.
You might be able to debug things by cleaning your $MYVIMRC (temporarily) and running gvim --noplugin.
Alternatively inspect all settings (like bufhidden and other suspect parties)
:set
:setglobal
and see from which script/plugin they are being set (bufhidden as an example only here):
:verbose set bufhidden
:verbose setglobal bufhidden
You might also inspect autocommands (that might prevent buffers from being wiped)
:verbose au
To avoid this I changed my alias:
g() { [ -z "$(command gvim --serverlist)" ] && command gvim "$#" || command gvim --remote-silent "$#" ; }
If the list of server is empty: launch plain gvim, otherwise launch with remote-silent option.
Is it possible to tell vim to save its viminfo file somewhere else?
Such as in the .vim folder
Try adding set viminfo+=n~/.vim/viminfo to your ~/.vimrc file. From :help 'viminfo':
n Name of the viminfo file. The name must immediately follow
the 'n'. Must be the last one! If the "-i" argument was
given when starting Vim, that file name overrides the one
given here with 'viminfo'. Environment variables are expanded
when opening the file, not when setting the option.
set viminfo='1000,nc:\\users\\abcdef\\_viminfo
This works for me in Windows 7.
I had a similar problem but had no write permission to my home folder (thus could not create the ~/.vimrc).
I solved it by modifying (through the Administrator) the _vimrc in C:\Program Files\VIM to include the line:
let $HOME = $USERPROFILE
I placed it at the beginning of the file and it worked well. Just in case someone comes across this question and this answer didn't work.
I know its quite a while now, but I am just mentioning this for future readers.
I was facing the same issue while trying to change the location for viminfo file in vimrc. At last setting the value of viminfofile option worked for me.
Added the following to my vimrc:
set viminfofile=D:\vim\viminfo
It works for me on windows with vim 8.2
TL;DR
This seems to be a bug in vim where set nocompatible is not idempotent and doesn't follow the principle of least astonishment.
As a workaround, either:
Ensure that you set nocompatible (or the equivalent set nocp) only once, and at the top of your vimrc.
Don't set it again if it's already set:
if &compatible | set nocompatible | endif " Avoid side effects if `nocp` already set
Explanation and bug illustration
From :help compatible (empahsis mine):
This is a special kind of option, because when it's set or reset,
other options are also changed as a side effect. CAREFUL: Setting or
resetting this option can have a lot of unexpected effects: Mappings
are interpreted in another way, undo behaves differently, etc. If you
set this option in your vimrc file, you should probably put it at the
very start.
Note that &viminfo is not listed in the side-effects, however the following lines clearly show the side effect upon &viminfo:
set nocompatible
set viminfo+=nWatch-my-viminfo-file-location-be-ignored
echom &viminfo
set nocompatible " do side effects even though nocomptible is already set
echom 'After 2nd "set nocompatible":'
echom &viminfo
Output:
'100,<50,s10,h,nWatch-my-viminfo-file-location-be-ignored
After 2nd "set nocompatible":
'100,<50,s10,h
vim --version | head -1
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Aug 05 2016 16:48:20)
Resolution
I have raised two GitHub issues regarding this:
Undocumented "set nocompatible" side effect upon &viminfo
set nocompatible not idempotent - setting produces side effects when already set
See also Vi StackExchange's question: Can't move viminfo file - &viminfo reverts upon loading vim which I raised before seeing this one.
The ordering of settings in the .vimrc affects the use of :set viminfo. The setting of viminfo should be after the setting of nocompatible. After reordering my .vimrc, the above solution to have the viminfo file be located in the .vim directory worked for me.
In gvim8.2 on Windows10, following option works to change path of viminfo :
set viminfofile=$VIM/.viminfo
Write this in .vimrc .
It could to change viminfo file path to under the $VIM.