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

[Juri Linkov <juri@linkov.net>]

>> Maybe then at least would be possible to display a message
>> that will list the names of dead buffers.  That might help
>> the users to restore the buffers killed accidentally.
>
> The name of a killed buffer is nil as long as the buffer object has not
> been collected.  But would buffer names be of great use anyway? Isn't it
> the name of the file, the info node, or the directory name the buffer
> was visiting that counts?

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

>> OTOH, this is not needed in case of using the tab-bar
>> because before switching to the tab with the killed buffer,
>> the name of the killed buffer is visible as the tab name.
>
> Does the tab-bar code store the buffer name separately?  But again -
> that name won't help you much anyway once the buffer was killed.

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.

> Incidentally, the name of the file a killed buffer was visiting will be
> available as long as the buffer object exists.  Do you mean that?

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.

>> Or maybe instead of 'post-set-window-configuration-hook' it's easy
>> to call a post-processing function after 'set-window-configuration'.
>
> 'post-set-window-configuration-functions' that's what I meant earlier -
> with the frame as argument.  But if a buffer is dead now, this won't
> help in neither regard.  First and foremost, 'set-window-configuration'
> must be able to deal with dead buffers in a safe fashion.  We could,
> optionally, display *scratch* in all windows that have a dead buffer now.

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?

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

>> BTW, there is another problem when the same buffer is displayed
>> in two tabs/window-configurations. For example, in the first tab
>> point is near the top of the buffer, and in the second tab point
>> is near the bottom of the same buffer.  The user edits the top
>> of the buffer in the first tab and saves writable window states
>> to the desktop.
>>
>> At this point, all positions saved in the second tab are wrong
>> because writable window states save point instead of the marker.
>
> But 'window--state-get-1' does
>
> 		(let ((point (window-point window))
>
> which should reliable give the value of point in window and then
>
> 		     (point . ,(if writable
>                                    point
>                                  (with-current-buffer buffer
>                                    (copy-marker point
>                                                 (buffer-local-value
>                                                  'window-point-insertion-type
>                                                  buffer)))))
>
> 'window--state-put-2' OTOH does
>
> 		  (set-window-point window (cdr (assq 'point state))))
>
> Do you see the problem here?

The problem is that for writable window states 'window--state-get-1'
saves point as a number from the marker.

>> One workaround is before saving the desktop to revisit all tabs
>> that will update points from markers in writable window states.
>>
>> But this won't help too much because there is still the same
>> problem after restoring the desktop.  When the desktop is
>> restored with right positions of all points, and the user
>> edits the top of the buffer in the first tab before visiting
>> the second tab, then after switching to the second tab
>> point will be at wrong position, because the tab is
>> restored from window states.
>
> So IIUC you mean that restoring the desktop (writable) does things
> differently than restoring tabs (non-writable)?  Can you tell me more
> precisely the order of desktop/tab-bar operations involved in that
> scenario?

The desktop saves writable window states with point as a number.
Switching tabs uses window configurations with point as a marker.

>> Here the same workaround is possible: to revisit all tabs after
>> restoring the desktop, that will create window configurations
>> from window states.
>
> I'd still have to understand: A non-writable state should behave like a
> window configuration.  A writable state should do the same but for using
> numbers instead of markers for positions.

Indeed.  Only writable window states saved to the desktop.

>> But automatically revisiting all tabs is too harmful
>> because some tabs might lost their names: when a buffer
>> was killed, then the tab will be renamed to the name
>> of the buffer that replaces the killed buffer,
>> and the user loses the hint what buffer was displayed
>> in the tab originally.
>
> Again I'm not sure how you would retrieve the name of a killed buffer.
> What am I missing?

Currently there is no solution to this problem.

>> To solve the problem of outdated points/markers in window states
>> maybe in addition to point, window states could also store
>> context strings like bookmark.el does?
>> I don't know how reliable these bookmark contexts are.
>
> It would help when the file a buffer is visiting was modified outside
> Emacs.  In all other cases, the stored point should suffice.

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