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

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

bug#33458: 27.0.50; dired loses position when reverted from outside plac


From: martin rudalics
Subject: bug#33458: 27.0.50; dired loses position when reverted from outside place
Date: Wed, 26 Dec 2018 10:42:40 +0100

> Oh, I see now why this case fails:
>
> (let ((_ (view-emacs-todo))
>        (w-c (current-window-configuration)))
>    (view-emacs-news)
>    (set-window-configuration w-c)
>    (previous-buffer))
>
> I expected it not to change prev/next buffers of the window
> saved in the window configuration, so the expectation for the
> last call to 'previous-buffer' was to return from the TODO buffer
> to the original buffer *scratch*.  But since the NEWS buffer
> meddled with the same window, this is not the case.

A window configuration is a state, a snapshot at some given instant of
time.  A window's previous buffers are a history, a sequence of statse
over a certain period of time.  What you want to do is freeze history.
We could do that by making a copy of all windows' previous and next
buffers, storing those lists in separate variables and restoring them
from there.

But note that any such change might mess up the partial ordering of
events on your system.  The relative positions of buffers in a frame's
buffer list would be incongruent with their positions in the buffer
lists of that frame's windows.  A new buffer you switched to while the
present configuration was saved and not yet restored would appear in
its frame's buffer list but not in that of any of the frame's windows.
This would imply that all windows of the frame were created after the
buffer was shown.

So I think you should first reconsider any such behavior.  Eliding
things from history "as if they never happened" is often a bad thing
(although I wish Emacs' 'undo' could do that occasionally).  And if we
wanted to implement it we would have to make it customizable.  Hence
any package would have to cater for both ways of seeing the history of
buffers in a window.

> This is why any code that saves window configurations has to care
> about creating a new window after the current-window-configuration
> call (thus removing the window saved in the window configuration),
> like I fixed now in https://gitlab.com/link0ff/emacs-wincows/commit/226cf229

Restoring the window configuration would remove the window.  What else
would you want to do with it?

BTW, window parameters have to be made persistent in order to make
them replace current ones when restoring a window configuration.

martin





reply via email to

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