From: Drew Adams <drew.adams@oracle.com>
To: T.V Raman <raman@google.com>,
"emacs-devel@gnu.org" <emacs-devel@gnu.org>
Subject: RE: [External] : Feature Request: Help: Display Relevant Bits First?
Date: Thu, 31 Mar 2022 20:50:41 +0000 [thread overview]
Message-ID: <SJ0PR10MB5488923144F598DEB28E693BF3E19@SJ0PR10MB5488.namprd10.prod.outlook.com> (raw)
In-Reply-To: <25158.3468.429616.238692@google.com>
> At present, if you do describe-function on any command that toggles a
> mode, you get a lot of common boiler-plate, with the salient bits
> about that particular function at the end -- could we reverse this?
The most salient info is the first line of the doc string:
Toggle syntax highlighting in this buffer (Font Lock mode).
But that's part of the text (you say) you want moved to
the end.
Anyway, I support your general proposal. I agree that
minor-mode boilerplate info should come after specifics
about the particular minor mode. It might even be good
to separate the two with a separator (e.g. line).
The problem of documenting minor modes has been around a
l o n g time. For a long time the boilerplate info was
only in the doc of `define-minor-mode' itself (but a few
minor-mode doc strings duplicated some of that info).
Eventually maybe we'll get to a place where `C-h f' for a
minor mode shows both the particular info (preferably up
front) and the generic (boilerplate) info, consistently
for all minor modes, and preferably with the two separated.
Either that or just show the particular info and (always)
provide a link to a single description of the generic
(boilerplate) info - IOW, factor that out. But introduce
that link by saying that it describes the behavior of all
minor modes (to make clear that it's part of the behavior
of this particular command).
next prev parent reply other threads:[~2022-03-31 20:50 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-31 20:22 Feature Request: Help: Display Relevant Bits First? T.V Raman
2022-03-31 20:50 ` Drew Adams [this message]
2022-03-31 21:01 ` [External] : " T.V Raman
2022-04-02 13:56 ` Lars Ingebrigtsen
2022-04-02 14:36 ` Basil L. Contovounesios
2022-04-02 14:53 ` Lars Ingebrigtsen
2022-04-02 17:13 ` T.V Raman
2022-04-03 11:54 ` Lars Ingebrigtsen
2022-04-03 0:37 ` Po Lu
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=SJ0PR10MB5488923144F598DEB28E693BF3E19@SJ0PR10MB5488.namprd10.prod.outlook.com \
--to=drew.adams@oracle.com \
--cc=emacs-devel@gnu.org \
--cc=raman@google.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).