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

[martin rudalics]

> 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