Open gilligan opened 11 years ago
I can't reproduce this when simply copying and opening that file.
@clausreinke This seems to come from the below code, which I believe is yours:
bufnr = int(vim.eval("bufloaded('" + file + "') ? bufnr('" + file + "') : -1"))
if bufnr != -1:
lines = vim.buffers[bufnr - 1]
else:
# etc
@marijnh yes, but I couldn't reproduce the issue, either. We do have a related bug #24 , where I suggested various debug outputs to try and look at ( @gilligan you could try some of those suggestions to see whether you can narrow down the issue). My suspicion was that the python list of buffers might get out of sync with vim's list (this is underspecified in the vim docs), but the debug outputs on the reporter's machine didn't back that suspicion.
As long as I can't reproduce the issues, I'm dependent on debug output from the reporters. And if that output says that everything seems to be fine, but things don't work anyway, I'm somewhat stumped:-(
Maybe, on the assumption that the buffer list exposed to python is buggy, go through an accessor function that does some sanity checking and swallows errors when accessing it? That's dirty, but might be better than random failures.
Though I guess we can also leave it as is until more reports surface.
This is somewhat out of the blue but : Wasn't there some rather evil change in the buffer numbering in vim at some point ? Other than that i'll try to narrow down the issue and let you know.
@marijnh it is just a suspicion, based on the location of the errors. So far, every check (including those in #24) has tended to confirm the one-to-one buffer mapping - no confirmation of that suspicion. Even if the suspicion was correct in some obscure cases, we couldn't give better error messages, and we couldn't ignore the errors, either. We need a reproducable test case.
It's a plugin that screws things up. I'll let you know details later.
It seems that Vim 7.4 has changed the behavior of vim.buffers object.
Quoted from https://gist.github.com/mjhea0/6200588
"Changed the behavior of |python-buffers| object: it now uses buffer numbers as keys in place of the index of the buffer in the internal buffer list. This should not break anything as the only way to get this index was iterating over |python-buffers|."
@jparera thanks. If I read that correctly, that will finally remove the ambiguity (whether or not index==bufnum).
Trying to rename pointless (via :TernRename with cursor on pointless) yields :
Traceback (most recent call last): File "", line 1, in
File "", line 343, in tern_rename
IndexError: no such buffer