From: Drew Adams <drew.adams@oracle.com>
To: Matthias Meulien <orontee@gmail.com>, 42325@debbugs.gnu.org
Subject: bug#42325: 28.0.50; [PATCH] Incomplete keymap in Bookmark Menu mode description
Date: Sat, 11 Jul 2020 13:28:34 -0700 (PDT) [thread overview]
Message-ID: <14cf9f7a-0c6b-4c26-b4b9-ee95a470ce15@default> (raw)
In-Reply-To: <87h7udzwuq.fsf@gmail.com>
> When one call describe-mode from *Bookmark List* buffer, the
> displayed documentation for the Bookmark Menu major mode displays
> an incomplete hard-coded keymap: The useful key /
> (bookmark-bmenu-search) isn't listed. I propose to rely on
> derived-mode-make-docstring to put the mode's keymap in mode
> docstring and to remove the currently hardcoded keymap
> description.
That's definitely a step backward, IMHO.
Just add `/' to the list.
A mode's `C-h m' documentation can, but need not,
list all of its key bindings. (It can also tell
users that they can use `C-h b'.)
But more importantly, it should describe the mode,
not just punt to say that it inherits from its
parent.
The doc of `derived-mode-make-docstring' should,
and I think does, make clear that it provides only
rudimentary, fallback help in the (hopefully rare)
case where there is no other such help.
"Construct a docstring for a new mode
if none is provided."
^^^^^^^^^^^^^^^^^^^
It doesn't say that it's a good idea to not
provide a doc string for a derived mode, and to
instead use this to construct one. Thank goodness.
Providing a doc string is normal. Not providing
one is to be avoided, and IMO, is a bug from a
user point of view.
There's little excuse for copping out and not
providing a doc string. There's even less excuse
for doing that for a mode's doc. And there's still
less excuse for _replacing_ hand-written help with
such a poor, generic, robotic fallback.
Please just do the right thing, adding the help
you think is missing. And provide whatever other
manual updates you think might help.
[To be clear, this doesn't affect me or my code.
Bookmark+ doesn't use the mode help provided by
vanilla bookmark.el. I'm just expressing my
concern for vanilla Emacs here.]
next prev parent reply other threads:[~2020-07-11 20:28 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-11 19:15 bug#42325: 28.0.50; [PATCH] Incomplete keymap in Bookmark Menu mode description Matthias Meulien
2020-07-11 20:28 ` Drew Adams [this message]
2020-07-18 7:55 ` Eli Zaretskii
2020-07-18 9:59 ` Matthias Meulien
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=14cf9f7a-0c6b-4c26-b4b9-ee95a470ce15@default \
--to=drew.adams@oracle.com \
--cc=42325@debbugs.gnu.org \
--cc=orontee@gmail.com \
/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).