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

From: martin rudalics <[email-masked]>
Date: Sat, 13 Jan 2024 11:38:56 +0100

>> IIUC 'dired-save-positions' and 'dired-restore-positions' are supposed
 >> to handle these bug scenarios in "normal" (user driven) dired reverting.
 >> Do they?  If so, why does saving and restoring a window configuration
 >> not use them?
 >
 > This is because 'dired-save-positions' and 'dired-restore-positions'
 > can't update positions in all existing window configurations
 > that are not yet garbage-collected.

So we'd need a persistent window parameter

(1) whose value is set to dired's file name at point in
'current-window-configuration'

(2) and allows to restore the window's point appropriately in
'set-window-configuration'.

For (1) we have two possibilities.  Either dired itself maintains it
every time its window point changes which is very tedious.  Or we make
the parameter a function that is run by 'current-window-configuration'
here:

		    /* If the window has a value for the parameter,
		       save it.  */
		    p->window_parameters = Fcons (Fcons (XCAR (par), XCDR (par)),
					   p->window_parameters);

When XCAR (par) is a function, that function would store the current
file name at the window's point in the cdr of the saved parameter.  This
would mean to offer one more facility for people to shoot themselves in
their foot.

For (2) we can either provide a hook that 'set-window-configuration'
runs or in

		    /* Always restore a non-nil value.  */
		    Fset_window_parameter (window, XCAR (pers), XCDR (pers));

restore the saved position when XCAR (pers) is a function - the file
name would be in XCDR (pers).  Not for the faint of heart either,
because of the current buffer/selected window dances in
'set-window-configuration'.

martin