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

From: martin rudalics <[email-masked]>
Date: Mon, 15 Jan 2024 11:24:06 +0100

>> 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