Loading ...
Sorry, an error occurred while loading the content.

45105Re: no winclose event

Expand Messages
  • A.J.Mechelynck
    Sep 27 2:17 PM
      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

      Best regards,
    • Show all 9 messages in this topic