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

[martin rudalics]

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

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

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

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

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

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

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

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

martin