-
-
Notifications
You must be signed in to change notification settings - Fork 62
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
cmd/govim: failed to resolve buffer #821
Comments
Thanks for the report - I was already investigating this thanks to a report from @leitzler. Fix should land shortly. This bug got introduced as a result of 8926dec which was backing out the broken changes introduced in 8826ef5. All of this would ideally by fixed by vim/vim#5694 (comment) |
In 8926dec we backed out the changes for tracking all buffer changes. But in so doing we didn't properly handle the situation where the busy state changes and the cursor is in a non-go file. Fix that and add a test to verify we don't regress. Whilst we are at it: * consistently use GOVIM_test_SetUserBusy in our testscript tests * slightly refactor the types/consts used for getting the current cursor position Fixes #821
@a-palchikov @aitva - I've just created #823 to fix this. Thanks for your respective reports, and apologies this slipped through. If you are able to give that PR a try that would be appreciated. However, per the commit message and test I'm fairly confident the issue is fixed. |
@myitcv I have tried it and I cannot reproduce the issue. 🎉 |
In 8926dec we backed out the changes for tracking all buffer changes. But in so doing we didn't properly handle the situation where the busy state changes and the cursor is in a non-go file. Fix that and add a test to verify we don't regress. Whilst we are at it: * consistently use GOVIM_test_SetUserBusy in our testscript tests * slightly refactor the types/consts used for getting the current cursor position Fixes #821
In 8926dec we backed out the changes for tracking all buffer changes. But in so doing we didn't properly handle the situation where the busy state changes and the cursor is in a non-go file. Fix that and add a test to verify we don't regress. Whilst we are at it: * consistently use GOVIM_test_SetUserBusy in our testscript tests * slightly refactor the types/consts used for getting the current cursor position Fixes #821
works for me as well. |
In 8926dec we backed out the changes for tracking all buffer changes. But in so doing we didn't properly handle the situation where the busy state changes and the cursor is in a non-go file. Fix that and add a test to verify we don't regress. Whilst we are at it: * consistently use GOVIM_test_SetUserBusy in our testscript tests * slightly refactor the types/consts used for getting the current cursor position Fixes #821
What version of Vim/Gvim are you using?
Vim/Gvim version
What version of Go are you using (
go version
)?What operating system and processor architecture are you using (
go env
)?go env
OutputWhat version/commit of
govim
are you using?56e86d7
Do the Vim channel,
govim
orgopls
log files show anything interesting?See below
What did you do?
I have a question about:
govim/plugin/govim.vim
Lines 219 to 220 in 56e86d7
Specifically if there is a reason to have
userBusy
callback for all filetypes (and not just Go).With
userBusy
configured for all filetypes, the unnamed buffers always fail withfailed to resolve buffer <bufnum>
afterupdatetime
.The issue is pretty similar to this.
What did you expect to see?
No failures on buffers govim does not know about.
What did you see instead?
Everytime
userBusy
is triggered inside an unnamed buffer, the vim shows an error (from the log file):The text was updated successfully, but these errors were encountered: