-
-
Notifications
You must be signed in to change notification settings - Fork 5.7k
Fixing buffer menu having stale items with terminal / cmdline window #5787
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
Conversation
I didn't add any tests, as I'm not quite sure how testing runtime files ( |
Hi,
On Sun, Mar 15, 2020 at 1:49 PM Yee Cheng Chin ***@***.***> wrote:
I didn't add any tests, as I'm not quite sure how testing runtime files (
menu.vim) should work, as they tend to go in at a later time. Otherwise I
could add a test that first loads in menu.vim, then makes cmdline-window
and terminal windows and test that the buffer menu grows and shrink
correctly.
You can use the Test_load_menu() function in testdir/test_menu.vim as an
example.
This test loads menu.vim and runs a basic test.
- Yegappan
|
Currently, when using special buffers like terminals / command-line window / quickfix / location list, these buffers will get added to the "Buffers" menu, but they don't get removed when the buffers are gone, leaving stale menu items. Fix buffer menu to be more robust. 1. Currently the buffer menu works by using the buffer name to add/remove the entries, but it's error-prone because the buffer could have been renamed under-the-hood. While it uses BufFilePre/Post autocommands to handle normal buffer renames, it doesn't work for the command-line window (accessible via `q:`) which gets renamed without sending the autocommand. Instead, change the menus to cached a dictionary a bufnum -> menu name, so it will always know how to remove a buffer from itself. 2. Add BufFilePre/Post autocommands to command-line windows when it changes the buffer name to "[Command Line]". 3. Add BufFilePre/Post autocommands to terminal windows when it changes the buffer name to the command, e.g. "!/bin/zsh". Either (1) or (2)+(3) will fix the issue, but just doing all of them as this seems like the right thing to do (2 + 3) also means the menu items show the correct names instead of just saying "[No Name]". This doesn't fix the following which needs to be fixed later: 1. Quickfix and Location List don't send BufDeleted autocmds. This leads to them also leaving stale buffer menu items as there's no way for the script to know that those buffers are gone.
0d759cf
to
f6b0296
Compare
Ok. I added a basic test that will load the buffer menu and add/remove command-line window and terminals, and confirm that the I can confirm that the test passes, and fails without my change. Edit: This test does require the runtime |
Currently, when using special buffers like terminals / command-line window / quickfix / location list, these buffers will get added to the "Buffers" menu, but they don't get removed when the buffers are gone, leaving stale menu items. Fix buffer menu to be more robust. 1. Currently the buffer menu works by using the buffer name to add/remove the entries, but it's error-prone because the buffer could have been renamed under-the-hood. While it uses BufFilePre/Post autocommands to handle normal buffer renames, it doesn't work for the command-line window (accessible via `q:`) which gets renamed without sending the autocommand. Instead, change the menus to cached a dictionary a bufnum -> menu name, so it will always know how to remove a buffer from itself. 2. Add BufFilePre/Post autocommands to command-line windows when it changes the buffer name to "[Command Line]". 3. Add BufFilePre/Post autocommands to terminal windows when it changes the buffer name to the command, e.g. "!/bin/zsh". Either (1) or (2)+(3) will fix the issue, but just doing all of them as this seems like the right thing to do (2 + 3) also means the menu items show the correct names instead of just saying "[No Name]". This doesn't fix the following which needs to be fixed later: 1. Quickfix and Location List don't send BufDeleted autocmds. This leads to them also leaving stale buffer menu items as there's no way for the script to know that those buffers are gone. Also add unit tests for cmdline-win / terminal buffer menus Note: This fix misc test_cmdline failures in MacVim due to the menu item not being able to be removed. This is a duplicate of vim/vim#5787
Thanks for looking into this and making a patch. We could just omit any kind of special buffers from the buffers menu, it's unlikely the user will want to select them. Except perhaps terminal buffers? |
I personally don't use the Buffers menu as well, but the stale menu item was causing some integration errors on MacVim-side, but also it's annoying to have stale items floating around.
I think this could work for quickfix (and I also don't think there is that much value in using I think there's still an inconsistency (bug?) that quickfix buffers generates Also, how do you feel about (2) / (3) (adding BufFilePre/Post events to command-line windows and terminal windows)? I guess the docs make it sound like it should only be for file-based buffers, but otherwise you have no way to know if a buffer has changed its buffer name. |
this was included with patch 8.2.0413 |
Hi, I think this commit introduced a bug where buffer menus now doesn't include any buffers at all (until refresh happens) due to how the This is also another bug where we attempt to check |
Currently, when using special buffers like terminals / command-line window / quickfix / location list, these buffers will get added to the "Buffers" menu, but they don't get removed when the buffers are gone, leaving stale menu items. Fix buffer menu to be more robust.
q:
) which gets renamed without sending the autocommand. Instead, change the menus to cached a dictionary a bufnum -> menu name, so it will always know how to remove a buffer from itself.Either (1) or (2)+(3) will fix the issue, but just doing all of them as this seems like the right thing to do (2 + 3) also means the menu items show the correct names instead of just saying "[No Name]".
This doesn't fix the following which needs to be fixed later: