GNU bug report logs - #13336
`next-frame' should not choose the *Backtrace* frame while debugging

Previous Next

Full log

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

From: martin rudalics <rudalics <at> gmx.at>
To: Drew Adams <drew.adams <at> oracle.com>, Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: "13336 <at> debbugs.gnu.org" <13336 <at> debbugs.gnu.org>
Subject: Re: bug#13336: [External] : Re: bug#13336: `next-frame' should not
 choose the *Backtrace* frame while debugging
Date: Wed, 25 Aug 2021 21:41:03 +0200

>> What would you have to "duplicate" here?
>
> "the parameters of `special-display-regexps'".
>
> I want the *Backtrace* frame to look and act like
> frames for other buffers whose names also match
> that regexp.

Why can't you add the `no-other-frame' parameter to that common list for
the *Backtrace* buffer alone?

>> Using `after-make-frame-functions' requires a
>> certain knowledge of Elisp.
>
> Meaning what - what "certain knowledge"?  I guess
> you're suggesting that I lack it, so it would be
> good to know what it is.

I lack it and that's why I neither use nor recommend using
`after-make-frame-functions'.

> I define the frame parameters separately, with a
> user option, `1on1-special-display-frame-alist'
> (which others besides myself use).  The setting of
> just `special-display-regexps' is in my init file,
> for myself alone.
>
> Put differently, I separate the appearance of
> special-display frames from a criterion (in this
> case buffer-name-matching-regexp) for which buffers
> get special-display frames.
>
> That's also the purpose, presumably, of option
> `special-display-frame-alist' (which option
> `1on1-special-display-frame-alist' augments).

And you cannot augment that alist by additional elements for specific
buffers?

>>   > I see.  How would I do that?  I don't control how or
>>   > when the frame gets created.
>>
>> Which means that you have to deal with a situation handled by
>> `special-display-regexps' once and `display-buffer-alist' now.
>
> Sorry, I don't know what you're referring to.
> Could you be specific?

These options have been provided to control the display of buffers where
the user does not "control how or when the frame gets created".

>> Because using `after-make-frame-functions' requires
>> a certain knowledge of Elisp.
>
> See above.
>
> Is there some specific caveat about using this hook,
> which is not in the Elisp manual?  Nothing particular
> is said in the manual about the hook.
>
> What special Elisp knowledge is required?  Why the
> vague formulation (repeated) of "a certain knowledge"?
> It's not clear to me what you're suggesting.

If you understand how frame names, explicit names and titles are set up,
you know much more than I do.  But in that case you should not have made
the wrong assumption about the name of the *Backtrace* frame at the time
`after-make-frame-functions' is run.  So what I am suggesting is that
since we both don't know all too much about this subject, it might be
better for us to avoid using `after-make-frame-functions' in code we
write.

martin

Previous Next

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