Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TernRename fails #32

Open
gilligan opened this issue Jul 18, 2013 · 8 comments
Open

TernRename fails #32

gilligan opened this issue Jul 18, 2013 · 8 comments

Comments

@gilligan
Copy link
Contributor

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
Copy link
Member

marijnh commented Jul 26, 2013

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
Copy link
Contributor

@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
Copy link
Member

marijnh commented Jul 26, 2013

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
Copy link
Contributor Author

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
Copy link
Contributor

@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
Copy link
Contributor Author

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

@jparera
Copy link

jparera commented Aug 11, 2013

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
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants