I've been using vim daily at work for almost 2 years now, and I've never really had any issues except for in the last two days...
My initial problem was that vim was using 8 spaces for tabs despite my settings in .vimrc. It even refused to let me reset the tab settings from within the vim instance itself. Furthermore, this problem was only happening when editing a specific file, and only while it was named a specific thing (i.e., renaming it fixed the problem). I assumed this must be due to some kind of per-file configuration that I was unaware of, and some searching led me to another post which prompted me to try the following command:
:so ~/.vimrc
This fixed my original problem, but I still don't know what caused it. I didn't do anything that I recall, it just sort of started happening as far as I can tell.
Today I deleted a swap file and all of the sudden my syntax highlighting is gone for a single file (the same one that was affected by the original issue). Again, renaming the file fixes the problem, and it running syntax on has no effect. This time :so ~/.vimrc doesn't alleviate the problem.
Does anyone have any idea what is happening here?
Update:
Thanks to Benoit's suggestion I found out that my vim was looking at a file in ~/.vim/view for some settings. When I moved this file, the issue was resolved (and vim created a new version). I'm still not 100% sure happened, but at least now I have something to look into.
Thanks Benoit!!
Your settings are probably modified by filetype specific files.
To know when a setting has been modified:
:verbose set setting?
for example:
:verb set tabstop?
:verb set expandtab?
:verb set shiftwidth?
Also, you could find autocmds for your file type:
:autocmd *.ext
probably some autocmd sets the file type, thus triggering .vim files that modify your settings.
FWIW, I've kept my vim settings in ~/.exrc for the last half-decade or so, without trouble.
Related
I'm having a weird issue with vim on Ubuntu. I've been using it for the last few weeks, trying to learn, on Windows and it behaves differently now that I'm using it on Linux.
I noticed that while in insert mode pressing backspace will delete text just like any other editor on Windows, but on Linux the text is "deleted" yet it stays there until I press ESC or write over it.
I was trying to fix this but I'm confused as to whether this is intended behaviour or not. It happens in gvim too.
The reason of this question is this, however:
I deleted my .vimrc file to see if any of my config was at fault and it fixed it. Backspace was now back to its regular self.
But then I tried creating an empty .vimrc file and that made it go back to the delayed delete. It's empty. Why the hell?
So I have no idea what's causing this. Hope my question makes sense my English ain't the best. Thanks.
Alright so looking at :h compatible I found this:
"When a |vimrc| or |gvimrc| file is found while Vim is starting up,
this option is switched off, and all options that have not been
modified will be set to the Vim defaults. Effectively, this means
that when a |vimrc| or |gvimrc| file exists, Vim will use the Vim
defaults, otherwise it will use the Vi defaults. (Note: This doesn't
happen for the system-wide vimrc or gvimrc file, nor for a file given
with the |-u| argument). Also see |compatible-default| and
|posix-compliance|."
So if I'm getting this right, running Vim with a .vimrc file should automatically set nocompatible and running it without one should set compatible... ? Whatever the case, I tried checking with :verbose set compatible? and it always says nocompatible is on so the -N flag shouldn't do anything... Yet it fixes the issue.
Without a vimrc Vim will load /usr/share/vim/vim80/defaults.vim (depending on your vim version). In this file the bs/backspace parameter is set to 2, or actually it is indent,eol,start which is the same as 2 (see :h bs)
Now if you create an empty .vimrc, defaults.vim will not be loaded, so your bs will possibly be 0.
This behaviour is described in :h defaults.vim
So to solve your problem, just put set bs=2 in your .vimrc
Alright I fixed it.
Running vim with the -N command makes it work properly. I'm not sure why but that's what's happening.
I am a new comer to the vim world, and I have just installed spf13-vim for a quick start. Apart from that I have not touched my .vimrc file.
I mainly use vim to write some python scripts on a remote server, so I have to type 'set ft=python' each time I open a file using vim. I am wondering if it's possible to edit my .vimrc file to make python a default choice of vim.
Another confusing thing is that each time I type a blank in vim, it shows a inverted question mark on my vim screen. I think it's because of some mismatch in file encoding, but I have no more idea about it.
I know it's a stupid question, but right now I can't solve it myself. Any help is appreciated.
Edit:
I have solved the problem of setting python default by write 'set ft=python' to my .vimrc file. (I didn't know contents in .vimrc are commands in vim) But I still don't know how to eliminate the inverted question mark when I typed a blank char, even after I do some search.
Name the buffer you're editing from the start, don't forget the :filetype plugin in your .vimrc and then things will work correctly.
In any way having :set ft=whatever in your .vimrc is twice wrong. First it'll apply to all new sessions opened without a file. Moreover it'll only apply to the first buffer. I.e. it won't work with :new.
I have weird issue with vim - for some files it doesn't color the syntax and opens it readonly mode by default, even if I use sudo. chmod for this file are 664, I am also owner of this file, so normally i shouldn't.
I have no set ro in my vimrc.
I noticed also that it often happens after removing .swp for this file - unfortunately, after this, this particular file is every time opened in readonly mode. One idea is - maybe is this some kind of spf13 cache?
For other files the behavior is correct.
Anyone knows this issue?
I found solution - it was more trivial than I expected.
I read the vim messages more carefully and I saw at the end:
if you did this already, delete the swap file `~/.vimswap/urls.py.swp`
So i did small investigation and i found .vimviews inside my /home directory. I just removed it's content and ...it works!
Probably spf13. There are WAY too many problems caused by spf13 in my opinion. Try doing :verbose set readonly? when you see the problem, to see where it happened from. My guess:
I think I remember spf13 having some kind of automatic session management built in, this would restore 'readonly' on a file if it had ever been set on that file.
It is quite possible (a fairly common solution) that if spf13 detects an existing swap file, it will automatically open the file in readonly mode, triggering (1).
It is also quite possible that some autocmd or another related to (2) sets an empty filetype or syntax, which would likewise be remembered by (1).
If this is the case, you can probably find the session file causing the issue (using that :verbose set readonly? command) and delete it.
Also consider, whether you really need all of spf13, or if you could achieve your desired configuration easier by installing plugins and configuring Vim yourself.
All of a sudden, my Vim starts with specifying fdm=marker regardless of the following two specifications
In _vimrc, both in the beignning adn bottom, set fdm=manual;
Per file type, have specified set fdm=manual through the *.vim files found in ~/vim/vimfiles/ftplugin.
Same setting had been working well around a week ago, when I updated the _vimrc. However, I just notice today that "marker" had been speificed for no reason.
Any suggestion? I have tried to Grep all the presences of "marker" in the ~vimfiles directory. This turned to be an unreasonable job to do, as there are thousands of presences of marker.
I have also tried to specify the following in my _vimrc, which did not work at all.
autocmd BufEnter * silent! set fdm=manual
fdm=manual will always pop up regardless of what type of file I open, upon typing set fdm in the command line. (by pressing :).
I have just made my Vim available on Github under: https://github.com/llinfeng/Vim
All the best,
-Linfeng
This is only a partial answer:
A plug-in called "restore_view.vim" is causing the problem. Upon uninstalling it, both settings I've tried did the work.
My guess is that, while _vimrc and "*.vim" files in ~/ftplugin/ did get sourced, the "restore_view" plugin will restore the "old view", which includes the folding methods and formatoptions, at the very end of the sourcing process. Therefore, all the previous settings of fdm and formatoptions had been restored and the newly implemented ones cannot be applied.
Here goes the github mirror of this plugin:
https://github.com/vim-scripts/restore_view.vim/blob/master/plugin/restore_view.vim
As a solution to my post, simply removing the plugin will solve all the issues. However, it remains to be an open question of how to properly deploy the "restore_view" plugin. I have emailed the author for suggestion and will also start a new question on Stack Overflow.
I have a problem to set my tags file correctly. It use to work without problem after I reinstalled the system. error message like
E433: No tags file
E426: tag not found: Pids
accurs when I press ctrl+].
I have this line in my .gvimrc file
set tags=~/projectdirectory/tags
and tags-exuberant installed properly.
It works fine when I type :set tags=~/projectdirectory/tags in gvim
I also tried use set tags=~/projectdirectory/tags;/
All other .gvimrc settings function well. How this could be possible?
UPDATE:
I have solved the problem, it is because I have multiple tags setting in ~/.gvimrc, vim take the last one in current session.
You can check the actual effective value (after starting GVIM) via
:verbose set tags?
The option might have been overwritten by a later :set command, or a plugin.
Even if you only use GVIM, it's recommended to put the general settings into ~/.vimrc (which is also sourced in GVIM), and keep ~/.gvimrc reserved for GUI-specific settings. An important difference between the two is that the latter is only sourced at the very end, so it's unsuitable for configuring plugins.