bug#68235: 29.1.90; Switching tabs stops following process output in selected window

[martin rudalics]

>> IIUC we have to move some point to some position somewhere in
>> 'set-window-configuration'.  Who would trigger that?  Calling a function
>> from within 'set-window-configuration' seems hairy to me.
>
> I see no other way than calling this hook from 'set-window-configuration'.

Agreed.  But I meant to use one or two hooks 'set-window-configuration'
would call.

> The problem is that running the hook afterwards would be too late.
> What I mean here is the annoying problem that when a buffer is killed,
> then on restoring a window configuration its window is deleted.

If there is only one window left, we have to show another buffer in it.

> This case could be fixed here with the same change as well.
> When a window parameter will contain a lambda called from
> 'set-window-configuration', this lambda could do something useful
> to preserve the window whose buffer was killed.  Something like
> displaying a placeholder with a button to restore the buffer.

We'd have to handle that here

      /* Scan dead buffer windows.  */
      for (; CONSP (dead_buffer_windows);
           dead_buffer_windows = XCDR (dead_buffer_windows))
        {
          window = XCAR (dead_buffer_windows);
          if (WINDOW_LIVE_P (window) && !EQ (window, FRAME_ROOT_WINDOW (f)))
            delete_deletable_window (window);
        }

which will be a bit hairy to be on the safe side.  This could not be
solved with a 'post-set-window-configuration-hook' because at that time
the window would have been deleted already.

> The same window parameter could be used in a window with
> a reverted dired buffer to move point to a previous file name.

Finding the right place to do that within 'set-window-configuration'
might be non-trivial.  Here using 'post-set-window-configuration-hook'
would be probably better.

martin