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

[martin rudalics via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

 > The buffer name often has a hint about the file/directory name.

But not the name of a dead buffer.

 > By default the buffer name is stored as a tab name.  And it helps
 > to know the purpose of why that tab was created.  When the buffer
 > was killed in another tab, it helps to decide whether the tab
 > that displayed the killed buffer should be closed as well.

How do you synchronize tabs with 'kill-buffer'?  If, in a tab, you
retain a link to a killed buffer, that buffer can't be collected as long
as the tab exists.  If you just keep the buffer name and the user
creates a new buffer with the same name but for a different file, things
may get confusing.

 > What would be more useful to keep for the killed buffer
 > is the value of its revert-buffer-function.  Often calling
 > this function can reconstruct the buffer contents.

But that function should be available even for a killed buffer as long
as its object is referenced by a tab.

 > Instead of *scratch*, is it possible to display some special buffer
 > that will display the name of the killed buffer, and a button
 > that runs its revert-buffer-function?

We can set up a buffer local variable whose value is a function that
'set-window-configuration' would call whenever it finds a window with
that buffer dead. 'set-window-configuration' would then check whether
that function correctly returned a live buffer to show in that window.
If the function succeeded, 'set-window-configuration' could try to
restore the earlier values of window point and start in the window.  If
the function failed, 'set-window-configuration' would either delete the
window or display *scratch* in it.

 >> Still 'post-set-window-configuration-functions' (and also the
 >> desktop routines) would have to know enough about how to restore the
 >> earlier state.  This is something only a buffer's major mode itself may
 >> know.
 >
 > Or revert-buffer-function.

Which is usually set up by the major mode.

 > The stored point is not sufficient when saved as a number to the desktop file.

In what sense?  You have a state you store in a desktop file and restore
from that file.  The stored state is immutable.  If a file whose buffer
is stored in that state gets modified in between, any positions stored
in the state must be considered invalid.

martin