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 [email protected].
For more options, visit https://groups.google.com/d/optout.
