-
Notifications
You must be signed in to change notification settings - Fork 365
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
Sometimes running neomake can change which buffer is showing in your window #17
Comments
Just adding a note here, this problem will be much more easily solved when some of the suggestions in neovim/neovim#901 get implemented, particularly |
Yes, having functions that operate on a buffer without having to navigate to it would be fantastic. The hacks you have to do to get some of this stuff to work are pretty gross. |
Just wanted to chime in this happens to me regularly. Must be my habit of saving a file and switching to another buffer quickly. I'm hoping there's a fix for this prior to neovim/neovim#901, since that could take awhile. |
Yes, I get this a lot as well. I save, switch to another split window and the previous buffer changes :( |
I have a partial fix for this. It's got a couple of issues of its own I'm trying to work out. Hopefully it will be complete soon. |
@benekastah++ 100 internet points if you fix this. |
Ok, this should be fixed now. I got rid of the fancy window/buffer switching code that I had before, which means that if you want to see the result of |
Seems to work great. Thanks @benekastah 👍 |
Fixed!!!!! 💸 |
Particularly when I do
:lopen
, sometimes a subsequentJobActivity
handler call will switch my file buffer into the loclist buffer. It has to do with the code in the handler that briefly switches back to the original window/buffer you were on when you invoked neomake to process the task.One potential solution is to only perform this work if the user is in the same window/buffer as they were when they invoked neomake. If they leave that window/buffer, defer the work until they return. Otherwise, we'll just have to make the current switching mechanism more robust.
The text was updated successfully, but these errors were encountered: