unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: martin rudalics <rudalics@gmx.at>, Lars Ingebrigtsen <larsi@gnus.org>
Cc: "13336@debbugs.gnu.org" <13336@debbugs.gnu.org>
Subject: bug#13336: [External] : Re: bug#13336: `next-frame' should not choose the *Backtrace* frame while debugging
Date: Wed, 25 Aug 2021 15:27:05 +0000	[thread overview]
Message-ID: <SJ0PR10MB5488895821941727F4B6E32FF3C69@SJ0PR10MB5488.namprd10.prod.outlook.com> (raw)
In-Reply-To: <ae3fed62-c7df-2db4-0050-b95173d8ae20@gmx.at>

>  > I could add a `*Backtrace*' entry to my value of
>  > `special-display-buffer-names', yes, and duplicate the
>  > parameters of `special-display-regexps' but also add
>  > the kludge to work around this bug.
> 
> 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.

>  > Is that necessary?  I was guessing it would be OK
>  > (and reasonable) to use `after-make-frame-functions'.
> 
> 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.

>  >> why on earth don't you use the FRAME-PARAMETERS idiom?
>  >
>  > It's not clear to me what idiom you have in mind.
> 
>  From the doc-string of `special-display-regexps':
> 
>    Alternatively, an element of this list can be
>    specified as (REGEXP FRAME-PARAMETERS),

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).

>  >>   > Debugging a bit shows that frame parameter `name' for
>  >>   > the *Backtrace* frame is indeed "*Backtrace*",
>  >>
>  >> Not at the time `after-make-frame-functions' gets called
>  >> (unless you specified a name for it).
>  >
>  > 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?

>  >> If you insist on using `after-make-frame-functions',
>  >> the following should work.
>  >
>  > I don't insist.  I was trying to interpret what you
>  > suggested.  Should I not use `after-make-frame-functions'
>  > for some reason (why)?
> 
> 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.

  reply	other threads:[~2021-08-25 15:27 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-02 18:13 bug#13336: 24.3.50; `next-frame' should not choose a frame (e.g. *Backtrace*) that did not exist when it was invoked Drew Adams
2017-01-30  6:33 ` npostavs
2017-01-30 14:32   ` Drew Adams
2017-01-31  3:22     ` npostavs
2021-08-23 14:37 ` bug#13336: `next-frame' should not choose the *Backtrace* frame while debugging Lars Ingebrigtsen
2021-08-23 15:20   ` bug#13336: [External] : " Drew Adams
2021-08-23 16:06     ` martin rudalics
2021-08-23 17:41       ` Drew Adams
2021-08-24  9:41         ` martin rudalics
2021-08-24 15:49           ` Drew Adams
2021-08-24 17:41             ` martin rudalics
2021-08-24 20:02               ` Drew Adams
2021-08-25  7:48                 ` martin rudalics
2021-08-25 15:27                   ` Drew Adams [this message]
2021-08-25 19:41                     ` martin rudalics
2021-08-25 20:23                       ` Drew Adams
2021-08-26  7:53                         ` martin rudalics

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=SJ0PR10MB5488895821941727F4B6E32FF3C69@SJ0PR10MB5488.namprd10.prod.outlook.com \
    --to=drew.adams@oracle.com \
    --cc=13336@debbugs.gnu.org \
    --cc=larsi@gnus.org \
    --cc=rudalics@gmx.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).