Charles E Campbell Jr wrote:
Bram Moolenaar wrote:
Charles Campbell wrote:
Just a suggestion -- I'd appreciate a WinClose event. BufWinLeave
would almost do, but if two or more windows are open on the same
buffer, then no event. WinLeave fires whenever one changes windows,
which isn't what I want, either. Unless I'm misunderstanding the
help for these two events.
What would this event be used for?
The WinResized event has also been suggested. It could be used to
update the Window layout. It will also be triggered when a window is
closed, since another window will get bigger then. Would it be
sufficient to only have a WinResized event? Would these events also be
triggered when closing the last window of a tab page?
As an example: I have debugging output in a left hand window (Decho.vim
produces this sort of output);
when I hit <f9> on a function name, a vertically split window shows up
on the right and tags to the
named function. However, if that window already exists, I just want to
re-use it, not split and create another
one. To do that correctly, I need that window, when it is actually
closed, to perform some cleanup (ie. make a change
in a script variable). I want to allow other vertical windows, so there
isn't necessarily a fixed number of vertically
split panes. Actually, the script also allows <s-f9> to create a left
hand source window: [leftsource|debugging|rightsource].
The leftsource and right source windows may well be open to the same
source file. Consequently the various buffer
closing events aren't adequate. BufWinLeave almost does the trick, but
there's that "not when a buffer is still visible
in another window" caveat associated with it. That's what I've been
using, but it really isn't adequate.
A WinResized might easily occur when that window wasn't closed, too.
Regards,
Chip Campbell
Yes, and it would happen on the resized windows, not the one which was closed,
but at least you could (if it existed) use it to check whether your windows
(which require cleanup) are still open. Or else, "closing" a window might be
regarded as "resizing" it to size -1 (size 0 is "window present, but not
active, and showing only the status line").
I suppose that if WinResize gets implemented, when resizing by dragging the
mouse it should trigger when releasing the mouse button, not as soon as the
status line moves, in order to avoid multiple triggerings when resizing by
more than one line; and I wonder: if 'equalalways' is set, it would trigger
for every window whenever a window (including a help window) is opened or
closed... Or else, have it trigger only once, <amatch> wouldn't be significant
then, and it would be the autocommand responsibility to check which window was
resized.
Best regards,
Tony.