Gary Johnson wrote:

> I've had an autocommand in my vimrc for quite some time that
> I noticed recently was causing the following error message when
> activated:
> 
>     Error detected while processing BufEnter Autocommands for "<buffer=3>":
>     E1312: Not allowed to change the window layout in this autocmd
> 
> I performed a git bisect on the Vim source and found that the bug
> was introduced here:
> 
>     d63a85592cef0ee4f0fec5efe2f8d66b31f01f05 is the first bad commit
>     commit d63a85592cef0ee4f0fec5efe2f8d66b31f01f05
>     Author: Bram Moolenaar <[email protected]>
>     Date:   Sat Nov 19 11:41:30 2022 +0000
> 
>         patch 9.0.0907: restoring window after WinScrolled may fail
> 
>         Problem:    Restoring window after WinScrolled may fail.
>         Solution:   Lock the window layout when triggering WinScrolled.
> 
>      src/errors.h         |  2 ++
>      src/ex_docmd.c       | 18 ++++++++++++-----
>      src/proto/window.pro |  1 +
>      src/version.c        |  2 ++
>      src/window.c         | 56 
> +++++++++++++++++++++++++++++++++++++++++++++++++---
>      5 files changed, 71 insertions(+), 8 deletions(-)
> 
> This is the autocommand in my vimrc and the reason for it being
> there:
> 
>     " If the Calendar window is open when the last non-Calendar
>     " window is closed, Vim continues to run with the Calendar
>     " window occupying the full Vim window.  Fix this,
>     " automatically close the Calendar window if it is the only
>     " window.
>     "
>     autocmd BufWinEnter __Calendar
>         \ autocmd BufEnter <buffer> if winnr("$")==1 | quit | endif

So you have a BufEnter autocommand that closes the buffer (with some
condition).  The BufEnter event can be triggered in various places, and
they are most likely not prepared for the buffer disappearing.

There already is quite a lot of code to handle side effects of what an
autocmd may do, but it's getting very complicated.  In some cases it's
better to just not allow certain actions.  For a BufEnter event it seems
quite natural to disallow deleting that buffer.  Why would you delete a
buffer you just entered?

Since this stuff is so complicated we keep finding new problems.  So
once in a while something that was allowed before is no longer allowed,
because there are situations where it causes a crash.

The situation you describe seems quite rare, thus I think we just have
to accept this no longer works.  You can probably find another way.


-- 
The psychic said, "God bless you."  I said, "I didn't sneeze."  She
looked deep into my eyes and said, "You will, eventually."  And, damn
if she wasn't right.  Two days later, I sneezed.  --Ellen Degeneres

 /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net   \\\
///                                                                      \\\
\\\        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
 \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

-- 
-- 
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].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/20221214131333.BE5FA1C0CF1%40moolenaar.net.

Raspunde prin e-mail lui