unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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.]





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