ternjs / tern_for_vim

Tern plugin for Vim
MIT License
1.83k stars 100 forks source link

TernRename fails #32

Open gilligan opened 11 years ago

gilligan commented 11 years ago
var f = function () {
    var pointless = 10;
    pointless += 1;
    return pointless;
};
f();

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

marijnh commented 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
clausreinke commented 11 years ago

@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:-(

marijnh commented 11 years ago

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.

gilligan commented 11 years ago

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.

clausreinke commented 11 years ago

@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.

gilligan commented 11 years ago

It's a plugin that screws things up. I'll let you know details later.

jparera commented 11 years ago

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|."

clausreinke commented 11 years ago

@jparera thanks. If I read that correctly, that will finally remove the ambiguity (whether or not index==bufnum).