From: thibaut.verron@gmail.com
To: Christopher Dimech <dimech@gmx.com>,
carlmarcos@tutanota.com, Emanuel Berg <incal@dataswamp.org>,
help-gnu-emacs <help-gnu-emacs@gnu.org>
Subject: Re: Generality of defvar
Date: Thu, 28 Jul 2022 11:37:35 +0200 [thread overview]
Message-ID: <95a861a4-56ab-de04-14a9-e0dbfee57253@gmail.com> (raw)
In-Reply-To: <trinity-3b520007-66cb-46a8-85c6-621dd230c240-1658993680100@3c-app-mailcom-bs15>
On 28/07/2022 09:34, Christopher Dimech <dimech@gmx.com> wrote:
> *Sent:* Thursday, July 28, 2022 at 7:06 PM
> *From:* "Thibaut Verron" <thibaut.verron@gmail.com>
> *To:* "Christopher Dimech" <dimech@gmx.com>
> *Cc:* carlmarcos@tutanota.com, "Emanuel Berg" <incal@dataswamp.org>,
> "help-gnu-emacs" <help-gnu-emacs@gnu.org>
> *Subject:* Re: Generality of defvar
> Le jeu. 28 juil. 2022 à 08:42, Christopher Dimech <dimech@gmx.com
> <mailto:dimech@gmx.com>> a écrit :
>
> *Sent:* Thursday, July 28, 2022 at 4:39 AM
> *From:* "Thibaut Verron" <thibaut.verron@gmail.com
> <mailto:thibaut.verron@gmail.com>>
> *To:* "Christopher Dimech" <dimech@gmx.com <mailto:dimech@gmx.com>>
> *Cc:* carlmarcos@tutanota.com <mailto:carlmarcos@tutanota.com>,
> "Emanuel Berg" <incal@dataswamp.org <mailto:incal@dataswamp.org>>,
> "help-gnu-emacs" <help-gnu-emacs@gnu.org
> <mailto:help-gnu-emacs@gnu.org>>
> *Subject:* Re: Generality of defvar
> Le mer. 27 juil. 2022 à 18:29, Christopher Dimech <dimech@gmx.com
> <mailto:dimech@gmx.com>> a écrit :
>
>
>
> > Sent: Thursday, July 28, 2022 at 1:47 AM
> > From: "Thibaut Verron" <thibaut.verron@gmail.com
> <mailto:thibaut.verron@gmail.com>>
> > To: carlmarcos@tutanota.com <mailto:carlmarcos@tutanota.com>
> > Cc: "Emanuel Berg" <incal@dataswamp.org
> <mailto:incal@dataswamp.org>>, "help-gnu-emacs"
> <help-gnu-emacs@gnu.org <mailto:help-gnu-emacs@gnu.org>>
> > Subject: Re: Generality of defvar
> >
> > Le mer. 27 juil. 2022 à 15:24, <carlmarcos@tutanota.com
> <mailto:carlmarcos@tutanota.com>> a écrit :
> >
> > >
> > > Jul 27, 2022, 13:21 by thibaut.verron@gmail.com
> <mailto:thibaut.verron@gmail.com>:
> > >
> > > > Le mer. 27 juil. 2022 à 14:52, carlmarcos--- via Users
> list for the GNU
> > > Emacs text editor <> help-gnu-emacs@gnu.org
> <mailto:help-gnu-emacs@gnu.org>> > a écrit :
> > > >
> > > >>
> > > >>
> > > >> Jul 27, 2022, 12:34 by >> incal@dataswamp.org
> <mailto:incal@dataswamp.org>>> :
> > > >>
> > > >> > carlmarcos--- via Users list for the GNU Emacs text
> editor wrote:
> > > >> >
> > > >> >> (defun enable-error-diagnostics ()
> > > >> >> "Enable error diagnostics with backtrace buffer.
> > > >> >> One can exit the debugger with the q command."
> > > >> >>
> > > >> >
> > > >> > You can refer to keys in docstrings like this:
> > > >> >
> > > >> > \\[forward-word]
> > > >> >
> > > >> > That way, it isn't hardcoded so if later
> changed/configured
> > > >> > it'll still show the right key.
> > > >> >
> > > >> How can I figure out what key to use in the docstring
> for exiting the
> > > backtrace buffer?
> > > >>
> > > >
> > > > The function bound to 'q' is quit-window. But since this
> function
> > > doesn't have a global binding, you need to tell the
> docstring to use the
> > > appropriate keymap to look the binding up.
> > > >
> > > > Something like
> > > >
> > > > "Enable error diagnostics with backtrace buffer.
> > > >
> > > > \\<backtrace-mode-map> (note: this is the part telling
> emacs where to
> > > look for the key)
> > > > One can exit the debugger with the `quit-window' command
> (bound to
> > > \\[quit-window])."
> > > >
> > > >
> > > Although quit-window is bound to q, the command
> \\[quit-window] just
> > > inserts
> > > M-x quit-window, rather than q.
> > >
> >
> > Yes, that's precisely because quit-window doesn't have a
> global binding.
> > You need to add \\<backtrace-mode-map> somewhere in the
> docstring to tell
> > emacs to show bindings for the backtrace buffers, rather than
> global
> > bindings.
> >
> > Best wishes,
> > Thibaut
>
> Sounds good advice, but the result could be
>
> Uses keymap ‘backtrace-mode-map’, which is not currently defined.
>
> My bad, it should have been debugger-mode-map.
> Not quite right yet.
>
> I guess one should also put (require 'debug) at some point along with
> the function definition?
> Seems more bother than it solves. Cannot see how users would be able to
> figure all this complication
> out.
For sure. But it's really a rare situation, and not one that is likely to hit first time users: one has to be writing a function with a docstring, and this docstring has to involve a key bound in a keymap defined in another file, and not loaded by default.
Even for users developing their own packages, usually the keymap will be defined in a file loaded at the same time as the function, completely hiding this subtlety.
Still, I would almost be tempted to consider this case a bug, and to expect that emacs should autoload debug.el to display the relevant information.
Thibaut
next prev parent reply other threads:[~2022-07-28 9:37 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-26 20:35 Generality of defvar carlmarcos--- via Users list for the GNU Emacs text editor
2022-07-26 23:01 ` Philip Kaludercic
[not found] ` <87r127h40s.fsf@posteo.net-N7wjq17--3-2>
2022-07-26 23:10 ` carlmarcos--- via Users list for the GNU Emacs text editor
2022-07-27 7:29 ` Thibaut Verron
[not found] ` <CAFsi02SEVCEjGNoQ6vPZvMw7d5F39JZAAPCR5VOUnzQDUERkQA@mail.gmail.com-N7yZ2U2----2>
2022-07-27 12:18 ` carlmarcos--- via Users list for the GNU Emacs text editor
2022-07-27 12:34 ` Emanuel Berg
2022-07-27 12:52 ` carlmarcos--- via Users list for the GNU Emacs text editor
2022-07-27 13:21 ` Thibaut Verron
2022-07-27 13:24 ` carlmarcos--- via Users list for the GNU Emacs text editor
2022-07-27 13:47 ` Thibaut Verron
2022-07-27 16:29 ` Christopher Dimech
2022-07-27 16:39 ` Thibaut Verron
2022-07-28 6:42 ` Christopher Dimech
2022-07-28 7:06 ` Thibaut Verron
2022-07-28 7:34 ` Christopher Dimech
2022-07-28 9:37 ` thibaut.verron [this message]
2022-07-28 13:57 ` Christopher Dimech
2022-07-26 23:16 ` Emanuel Berg
2022-07-26 23:23 ` Emanuel Berg
2022-07-26 23:36 ` carlmarcos--- via Users list for the GNU Emacs text editor
2022-07-27 4:57 ` Yuri Khan
2022-07-27 6:59 ` carlmarcos--- via Users list for the GNU Emacs text editor
2022-07-29 15:56 ` Emanuel Berg
2022-07-29 16:25 ` [External] : " Drew Adams
2022-07-30 3:56 ` Emanuel Berg
2022-07-30 19:36 ` Drew Adams
2022-08-01 3:24 ` Emanuel Berg
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=95a861a4-56ab-de04-14a9-e0dbfee57253@gmail.com \
--to=thibaut.verron@gmail.com \
--cc=carlmarcos@tutanota.com \
--cc=dimech@gmx.com \
--cc=help-gnu-emacs@gnu.org \
--cc=incal@dataswamp.org \
/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.
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).