I've investigated a bit further to see how much impact this bug has. It turns out that it does not get triggered when opening a new tabpage first (or when calling `settabvar` before `gettabvar`), replacing step 1 from below with:
vim -u NONE -N --cmd 'tabnew | call gettabvar(1, "bar") | au BufEnter * echom "TRIGGERED"' This indicates that `switch_win` probably fails, because `tp->tp_firstwin` is not valid/set - which might indicate another problem. Therefore the root issue here is that `switch_win` fails, which then triggers the bug my patch [1] is supposed to fix. Additionally I believe that `unblock_autocmds` (https://github.com/vim-jp/vim/blob/master/src/fileio.c#L9586-9598) should check if the counter `autocmd_blocked` gets negative and output some error, because this is not meant to happen and would have pointed out the initial problem with `f_getwinvar` then. Regards, Daniel. 1: see my previous mail in this thread for the patch, also at https://github.com/blueyed/vim/compare/fix-switch_win-no-unblock_autocmds.patch On 13.09.2014 22:12, Daniel Hahler wrote: > Oh, what a nasty bug! > > After having debugged eclim to find out what might trigger this it comes down > to be reproducible like this: > > 1. Start vim: vim -u NONE -N --cmd 'call gettabvar(1, "bar") | au BufEnter * > echom "TRIGGERED"' > 2. Remove the initial message, e.g. ":<cr>" > 3. Open the cmdline-window: q/ > > The BufEnter autocommand (and likely WinEnter also) gets triggered, if > `gettabvar()` has been called with the current tabpagenr(). > It does not happen when using "0"or a non-existing tab with gettabvar. > > The reason for this is that in `switch_win` in `f_gettabvar` will unblock > autocommands on failure, although that is what `restore_win` is meant to do. > (code reference: > https://github.com/vim-jp/vim/blob/master/src/eval.c#L12087-12101) > > The attached patch fixes this, according to the doc comment from `switch_win`: > * restore_win() MUST be called to undo. > > It adjusts two other places where the code was returning on > switch_win-failure only. > > Please consider adding tests for this. > > This bug appears to exist since 7.3.963 probably > (https://github.com/vim-jp/vim/commit/b4af40af94851dcd1327c7a65c6da8d72937053d). > > There is also a call to `block_autocmds` in `free_all_mem` without a > corresponding call to `unblock_autocmds`, but that might be expected?! I have > not checked where this is used. > > Patch URL: > https://github.com/blueyed/vim/compare/fix-switch_win-no-unblock_autocmds.patch > > > Regards, > Daniel. > > Am Samstag, 13. September 2014 19:49:59 UTC+2 schrieb Daniel Hahler: >> It appears that &buftype is not correctly set with the BufEnter autocommand >> for a cmdline-window. >> >> I've noticed this with a BufEnter autocommand that checks for &buftype, and >> the documentation states that it should be "nofile" for the cmdline-window, >> but it's empty. >> >> Additionally, according to the documentation, BufEnter shouldn't get >> triggered at all for a cmdline-window (from cmdline.txt): >> >>> Two autocommand events are used: |CmdwinEnter| and |CmdwinLeave|. Since >>> this >> window is of a special type, the WinEnter, WinLeave, BufEnter and BufLeave >> events are not triggered. >> >> >> I've seen a similar oddity before, where &buftype appeared to be not current >> with a WinEnter autocommand, and in that case it helped to use BufEnter. >> >> >> Regards, >> Daniel. > -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.