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.
Related
I have a weird hard-to-localize issue with vim. It's almost certainly a weird custom configuration that is my fault, but I don't know (1) what I should be looking for and (2) how to reproduce it. I don't know if anyone will be able to help, but its been plaguing me for years, so I thought I'd at least make a post about it.
The issue is that after using vim, I occasionally find weird files in the directories I was working. The file names were usually characters I was typing. I have absolutely no idea what is triggering this, and it doesn't happen that often, so its hard to simply comment out a piece of my vimrc check if it occurs and narrow it down that way.
Examples of the file names I get are:
= np.diff(bins)
ep='')
= {
(shape0, device=device"
_rect = cv2.undistortPoints(left_corners, cameraMatrix, distCoeffs)
elf.alt_fc = nh.layers.MultiLayerPerceptronNd(
=feat_dim, noli=swish,
hape0 = (
ys, ubelt
tates, evidence=evidence)
ample_input = torch_encoder_result
tack = kwimage.stack_images(imgs, axis=1, resize='smaller')
hear_range=(-10, 10)
There is nothing in common between the files names that I can see. The majority have an "=" and a paren, but not all. I really have no idea how to reproduce this error. I feel like I must have a habit of hitting an incorrect key stroke that causes this issue, or there is some plugin doing something weird, or I have a crazy configuration (which I do).
The contents of the files varies. Sometimes they look like git differences. The one from the first example was the page for "less --help" (yes I grepped for that). Another is what looks like a docstring for a python class (I'm not 100% sure if this only happens with Python files, because most of my vim usage is Python).
Any tips that anyone has for how to further debug this would be appreciated.
Just for reference this is my vimrc: https://github.com/Erotemic/local/blob/master/vim/portable_vimrc and it does reference and source several other files in that repo, so I don't expect anybody to be able to parse it and figure it out.
If I was to take a guess I'd say its probably an auto-commands that's doing it, and I do have all of those auto-commands defined in this file: https://github.com/Erotemic/local/blob/master/vim/rc_settings/autocommand_settings.vim but I don't see anything that would cause this 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
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!
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