I've searched for some time now and nobody seems to have the problem I do. I've got vim set up to use the colorscheme I like and it was all working perfectly until I opened a file that had a swap. I got the usual message asking if I wanted to delete it, read only or recover it. I selected recover and after doing so I've been unable to get that one file to display the colors I want.
I've tried the usual syntax:on, reloaded .vimrc and just about every normal step required to get the highlights. The strange thing is that the problem is only present for this one file when it's in the directory I recovered the swap from. Any other file I open has the colors working as usual, and if I rename the troublesome file or put it in another directory it loads the colors fine.
I figure vim must be storing its path somewhere but I have no idea where. I tried deleting .viminfo but that did nothing. Any input is greatly appreciated.
Sorry, I'm new to Stackoverflow. I think this is more useful as an answer to my own question than a comment:
:colo outputs "torte" and se ft? outputs "filetype=" I tried the same commands on other files and se ft? outputs "filetype=cpp". I searched for how to set the filetype and set filetype=cpp fixed the issue. Thanks Balthamos for pointing me in the right direction!
Related
EDIT: it turns out if I write to a temporary .go file in the same directory I can then start writing the file again, so I'm almost certain this is a vim-syntastic issue. Going to mark this as closed.
I have an infrequent (but extremely annoying) bug where vim gets confused about where a file is supposed to be written to. It will suddenly decide that it should be writing to "-stdin-", even though :echo expand('%:p') is showing the correct file.
When this happens, there's basically no way to write the buffer back to the correct file. :w % doesn't help, nor does :w NameOfFile.go. I can write to a different filename just fine. :bd does not fix the issue. This only happens if there's a location list open.
Given the lack of google hits for this, I'm guessing this is some kind of issue with my local config. How can I go about debugging this problem?
Edit to add: after posting this, I realized that this is very possibly related to vim-syntastic. I've opened an issue there, but it's definitely possible there's something else causing this.
Marking as closed since this appears to be a vim-syntastic issue.
I noticed that for whatever reason, my _vimrc wasn't being loaded this morning. I keep my entire vim directory saved to my Google Drive to the location I specify in my _vimrc. I didn't worry about it since I'd recently backed it up, but now when I dump it into my vim folder, whenever I start up gVim, it looks like it renames it to _vimrc.2014.
I can't find anything about this behavior, is it normal? It doesn't really affect me too much since it still gets source, but I just want to know why it's doing that.
Vim certainly is not doing this. I'm not certain it's causing YOUR problem, but Google Drive has problems replacing files with a new file of the same name. Under the hood, that is exactly what Vim is doing when it writes a file with default settings. See https://groups.google.com/d/topic/vim_use/jkw_nnHz9cE/discussion : you can use either the 'backupskip' or 'writebackup' options to force Vim to write the file directly instead of replacing it with a new file when editing inside your Google Drive folder. I'm using this line in my .vimrc to accomplish the task:
let &backupskip.=','.expand('$HOME/Google\ Drive/').'*'
Very often (as in multiple times an hour), when I save my file :w, vim tells me "E13: File exists (add ! to override)"
I don't know why it does this, I can't reliably reproduce it, it feels random.
This is my vimrc, note that it sets nobackup, nowritebackup, and noswapfile, and there is a function to strip trailing whitespace that gets run when I save a file.
Also, I tend to have 20 vims open at once, all backgrounded, often editing the same file. Also not improbable that I have the same buffer open in multiple windows (ie :vsp) and might open it, then reopen it with the e command a lot, possibly from a relative filepath, or possibly from an absolute one (the cmap %/ <C-R>=expand("%:p:h")."/"<CR>). No idea if any of this matters. Next time I have this issue, I'll check my ls and report anything odd.
Update:
When I tried to save "lib/seeing_is_believing/wrap_expressions.rb" (note that this is a different file than the one in the gif), this happened again. Here is the ss, it's buffer 3:
Update2 (for #mMontu)
I just realized that there are two errors happening here. The one in the screenshot is the readonly thing. The one in the gif is the more common one, E13: File exists (add ! to override)
The one I just hit is E13 File exists, for this one, readonly is not set:
Update 3
I'm pretty sure the problem is the ZoomWin plugin. I had switched it up to a newer version, and it simply didn't work right. So I stopped using it for a bit, and didn't have this issue. Then switched it back, b/c I miss its functionality (it's my favourite vim plugin), and the problems started again. Possibly it's ZoomWin in conjunction with NerdTree window. Probably not the lib authors' faults, vim in general seems fragile and buggy. Maybe I'll try NeoVim, see if they've done a better job. Maybe it's time to try Atom or Emacs again.
It seems that if there were read errors opening the file, Vim will print an error on :w. This can be seen by running :f:
"MANIFEST.in" [Read errors] 1 line --100%--
The errors aren't necessarily errors in reading the contents of file; they can be caused by a plugin.
I think the main problem is that the file has been modified externally, see http://vim.wikia.com/wiki/Have_Vim_check_automatically_if_the_file_has_changed_externally to reload it whenever this happens
The situation: I was using vimwiki, I stopped for a brief flirtation with emacs/org-mode, and then ran screaming back to vim. I figured it was a good time to clean up my kludgy setup, and so I started with a fresh ~/.vim directory, installed pathogen, and I've been adding packages that way.
What's very strange is, when I go to start a new vimwiki index file, I get the message:
Vimwiki: Make new directory: /home/thomas/Dropbox/wiki/wiki
despite my .vimrc containing instead
let g:vimwiki_list = [{'path':'~/cerebra/wiki', 'path_html':'~/cerebra/export/html/'}]
That is to say, it's trying to save the wiki in a place almost, but not quite, like my previous vimwiki installation, and ignoring the new setting I've given it.
I bet if I understood how to use find with grep I could find where this setting is so that I could delete it. I examined each file in ~/.vim/bundle/vimwiki, and found no instance of the word "Dropbox" there, and it's nowhere in my vimrc.
from the comments, it turns out, your $HOME/cerebra is a softlink to /home/thomas/Dropbox/wiki.
So vimwiki works just fine.
small suggestion:
You could consider to create a link in dropbox, not the other way round. dropbox supports it.
This is my issue with Vim: you have it open for a couple of days. You're ready to close vim. You don't necessarily want to save all files... you want to skip any files which don't have modified changes, and you want to be left (or be asked) what you want to do with the remaining buffers with unmodified changes…
For anyone that has used Photoshop, this is very familiar… you use it for a week, and when you close Photoshop, it is really trying to close the application, and skips all files which haven't been touched, let's you chose what you want to do with the remaining files, and then closes itself.
It seems like every time I close Vim, I have to go through this circus of doing :qa, then running into a file, doing :bd!, then doing :qa again, run into a file I want, :w, and it's just a huge pain. There has to be a better way of doing this.
If it isn't already obvious… I have :set hidden in my .vimrc.
How about
:confirm qa
It asks you for each modified file whether to save or abandon it (or all remaining). This is the same behavior that GVIM exhibits when you close it via the X in the window title.
does :xa! solve your problem ?
:xa[ll]! Write all changed buffers, even the ones that are readonly,
and exit Vim. If there are buffers without a file name or
which cannot be written for another reason, Vim will not quit.
I was able to find the plugin BufOnly, and then with the help of someone else on StackOverflow, I got an answer that satisfies me:
https://stackoverflow.com/a/14690570/240287