GNU bug report logs - #68235
29.1.90; Switching tabs stops following process output in selected window

Previous Next

Full log

View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Juri Linkov <juri <at> linkov.net>
Cc: daniel.c.mccarthy <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>, 68235 <at> debbugs.gnu.org
Subject: bug#68235: 29.1.90; Switching tabs stops following process output in selected window
Date: Wed, 17 Jan 2024 12:42:44 +0100

> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.