bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Juri Linkov
Subject: bug#68235: 29.1.90; Switching tabs stops following process output in selected window
Date: Mon, 15 Jan 2024 19:53:13 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu)

>       /* Scan dead buffer windows.  */
>       for (; CONSP (dead_buffer_windows);
>          dead_buffer_windows = XCDR (dead_buffer_windows))
>       {
>         window = XCAR (dead_buffer_windows);
>         if (WINDOW_LIVE_P (window) && !EQ (window, FRAME_ROOT_WINDOW (f)))
>           delete_deletable_window (window);
>       }
> which will be a bit hairy to be on the safe side.  This could not be
> solved with a 'post-set-window-configuration-hook' because at that time
> the window would have been deleted already.

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.

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.

>> The same window parameter could be used in a window with
>> a reverted dired buffer to move point to a previous file name.
>
> Finding the right place to do that within 'set-window-configuration'
> might be non-trivial.  Here using 'post-set-window-configuration-hook'
> would be probably better.

Or maybe instead of 'post-set-window-configuration-hook' it's easy
to call a post-processing function after 'set-window-configuration'.

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.

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.

Here the same workaround is possible: to revisit all tabs after
restoring the desktop, that will create window configurations
from window states.

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.

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]