tree c03c09e722515ed74ceea5e43e220334e0ec38af
parent 0fd44a5ad81ade342cb54d8984965bdedd2272c8
author Sean Dewar <6256228+seandewar@users.noreply.github.com> 1708462351 +0100
committer Christian Brabandt <cb@256bit.org> 1708462351 +0100
gpgsig -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEETxlwiBaRjhmq4Z3u8/kto4P93gkFAmXVEesACgkQ8/kto4P9
 3gl3hw//fRgrvHQEI+J6DEXxb1nXI1fk2nDJA+JtFUbjf1+o5fcHtPVHOPlOaodo
 5KQBA6lB1VUgLGxytbjqFPQOmJi42CaRuLYd/I4kEspQvbXCwqionDM5OtX4XEpW
 1JexgcMYaH7x2pcyzWWAZP6gAK1vIutZrdD82mcQzfPEC/E8d3+Ymq3LWz2HCnII
 YwzdaSkXpyfiqFBj8GH8IzMX7Lr9SPIhF0Gk7zM22b7eVmB4bAHgjesONze2Zltc
 QtrVg7EmV6dG4uEhoW6zoUpZ8IdtcoZjlub7CS66EdrvEYc6N+hsgZMcbGwUh9K0
 DfysfIFdGO61/KeXZt9L4rqqGlZKKvnPZ0lUw8LIHCiAyIJAxNATQ4YcHXSbuS2w
 sGiDbotqY7mJvfQ9uILJTF1eu1StXxO6WdePqQWXMsIlDwG1VetvjCGcKJSNAGjB
 gPfEt0oCrbHSa0FuHytSxwA87twgM8bnnWWaIzKhZA5pRU1OM49sUy1C/pfnKxFv
 c0Jk+Nmzw+SEO6bmsPTyFi1LwJnzEoGQ+7DoYQw94IHwp7ZJUHxbSYx9TdnbebOf
 YKOoWR2/8cWBxZkIZ/HucMPLuxMaZCoPH30ZclNAclYQW8r1ebqa48Oa2zdNy0+0
 7vyxV2Y/JFoSGYWSS5cQMemQqQcdXPaHT4Y3KzjO645kWqxVsgs=
 =1eai
 -----END PGP SIGNATURE-----

patch 9.1.0117: Stop split-moving from firing WinNew and WinNewPre autocommands

Problem:  win_splitmove fires WinNewPre and possibly WinNew when moving
          windows, even though no new windows are created.
Solution: don't fire WinNew and WinNewPre when inserting an existing
          window, even if it isn't the current window. Improve the
          accuracy of related documentation. (Sean Dewar)

Likewise, before this patch, WinClosed was not fired anyway (even for :wincmd
H/J/K/L, which also didn't fire WinNew, but did still fire WinNewPre), despite
documentation saying windows are "closed". Note that :wincmd T actually indeed
works by creating a new window (and closing the old one), unlike the others.

This also fixes issues where WinNewPre is fired when split-moving while curwin
doesn't yet have a frame or entry in the window list, causing many things to not
work (it's not considered valid at that point). This was guaranteed when using
:wincmd H/J/K/L.

Because WinNewPre is no longer fired when split-moving, this makes restoring the
previous window layout on failure easier, as we can be sure that frames are not
resized from WinNewPre autocommands if win_split_ins fails. This allows us to
use a different strategy in the following commit.

--

In my opinion, this leaves questions about the current usefulness of WinNewPre.
A motivation described in #10635 states how creating a new window can steal room
from other windows, and how WinNewPre will be useful for detecting that, but
this is also true when inserting an existing window, which now doesn't fire it.
Maybe the autocommand should be changed to have a better name?

There are also other issues I found with the current implementation of WinNewPre
that need addressing:

- it allows switching windows and tabpages, which can cause incorrect windows to
  be split/moved, and big problems when switching tabpages.

- it fires before win_split_ins checks for room, before it makes any changes to
  window sizes or before it considers allocating a new window. This should be
  changed or documented.

I hope to address some of this stuff in a different PR, if possible.

related: #14038

Signed-off-by: Sean Dewar <6256228+seandewar@users.noreply.github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>