[Top][All Lists]

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

bug#32825: 27.0.50; Deterministic window management

From: martin rudalics
Subject: bug#32825: 27.0.50; Deterministic window management
Date: Wed, 14 Nov 2018 09:33:42 +0100

>> (defcustom switch-to-prev-buffer-skip-regexp
>>    "\\*Backtrace\\*\\|TAGS"
> Sorry, this list looks too ad-hoc.  And why there is no *Edebug Backtrace*?
> *Edebug Backtrace* should be treated exactly the same way as
> *Backtrace*, but in practice this means adding a whole bunch
> of same variables
> debugger-previous-window
> debugger-pre-previous-window
> debugger-previous-window-height
> ...
> to edebug.el
> edebugger-previous-window
> edebugger-pre-previous-window
> edebugger-previous-window-height
> ...
> and duplicating all related code.  This doesn't look right.
> I think that either we should generalize display-buffer-in-previous-window
> to avoid such duplication, or better never display temporary buffers
> in unrelated windows at all, i.e. to replace display-buffer-in-previous-window
> in the action list with display-buffer-below-selected and
> display-buffer-at-bottom.

Pardon me, aren't you confusing 'display-buffer-in-previous-window'
with 'switch-to-prev-buffer' here?  The change I propose doesn't
affect 'display-buffer-in-previous-window' at all.  It simply should
avoid that 'switch-to-prev-buffer' shows such a buffer.  Also, while
'display-buffer-below-selected' and 'display-buffer-at-bottom' usually
do what they are intended to do they may also reuse an existing window
when splitting fails.

> This is exactly what we already do for displaying other temporary
> buffers like *Marked Files*, *Completions*, etc.

FWIW most of these are killed immediately after fulfilling their
purpose.  Setting 'debugger-bury-or-kill' to 'kill' would do the same.


reply via email to

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