GNU bug report logs - #32825
27.0.50; Deterministic window management

Previous Next

Package: emacs;

Reported by: Juri Linkov <juri <at> linkov.net>

Date: Mon, 24 Sep 2018 19:15:02 UTC

Severity: minor

Tags: moreinfo

Found in version 27.0.50

Fixed in version 29.0.50

Done: Juri Linkov <juri <at> linkov.net>

Bug is archived. No further changes may be made.

Full log


Message #314 received at 32825 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 32825 <at> debbugs.gnu.org
Subject: Re: bug#32825: 27.0.50; Deterministic window management
Date: Thu, 22 Nov 2018 01:54:58 +0200
>> But displaying a temporary buffer could add a "tab" to the end of the
>> tab-bar, this means at the end of the list of next-buffers:
>>
>> [buffer-A] [buffer-B] [buffer-C] [buffer-D] [buffer-E] [temp-buffer]
>> prev-buffers                                         current-buffer
>
> The problem with this approach is as follows: The list of next buffers
> is usually empty because it contains only the buffers visited while
> navigating the list of previous buffers backwards in time.  It's main
> purpose is to revert any overshooting during such navigation.  But
> this means that when you add your temporary buffer to the (usually
> empty) list of next buffers, overshooting while reverting the
> overshooting will get you to that temporary buffer immediately.

What buffer does it show now in this case?  Is it a more predictable
buffer than would be in case of a previously displayed temporary buffer?

>> After exiting from this temporary buffer, it could be kept in the
>> list of next-buffers:
>>
>> [buffer-A] [buffer-B] [buffer-C] [buffer-D] [buffer-E] [temp-buffer]
>> prev-buffers          current-buffer                    next-buffers
>>
>> Then returning to prev-buffers (e.g. with kill-buffer) will not visit
>> this temporary buffer.  But display-buffer-reuse-window could look for
>> a previously displayed buffer in the list of next buffers.
>
> The main purpose of a window's list of next buffers is that of undoing
> a 'switch-to-prev-buffer' step.  I have no idea which consequences
> your proposal could have apart from the one I sketched above.  I'm
> already no great friend of
>
>      If there is no recent invocation of `switch-to-prev-buffer' that
>      can be undone, this function tries to show a buffer from the
>      buffer list of the frame WINDOW appears on ...

And this is usually some random unpredictable buffer.

> but this comes from an attempt to model buffer switching like 'undo'
> does.

undo/redo is a good analogy.




This bug report was last modified 3 years and 24 days ago.

Previous Next


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