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

Previous Next

Full log

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 32825 <at> debbugs.gnu.org, Noam Postavsky <npostavs <at> gmail.com>,
 Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#32825: 27.0.50; Deterministic window management
Date: Tue, 02 Oct 2018 15:24:56 +0200

martin rudalics <rudalics <at> gmx.at> writes:

> Users have all possible freedom in this regard.  Your "always use a
> special, but always one and the same frame" would have to be specified
> more precisely but there is no reason it cannot be done.  For example,
> users who want to use a dedicated frame for that purpose can write
> their own 'my-display-backtrace' function which creates that frame if
> necessary, remembers it in a variable of their choice, and reuses it -
> from that variable - in a later invocation.

Well, right.  It wasn't clear to me that `display-buffer-alist' takes
precedence over the ACTION arg of `pop-to-buffer'.  You can just define
your own action function.

> I'm afraid that yours is yet another example of how difficult it is to
> customize 'display-buffer-alist'.

I fine with it.  There are lots of different possible semantics, so it's
natural that some of them make defining a new function necessary.

The special thing in this example is that the action has to have a state
(remember the last window), so you have to use a closure.  Or you can
just use the value of `debugger-pre-previous-window'.  Seems acceptable
to me.


Michael.

Previous Next

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