unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Lars Ingebrigtsen <larsi@gnus.org>
Cc: "36500@debbugs.gnu.org" <36500@debbugs.gnu.org>
Subject: bug#36500: [External] : Re: bug#36500: 26.2; Minor mode doc strings - say what the current mode-variable value is
Date: Tue, 22 Jun 2021 15:10:03 +0000	[thread overview]
Message-ID: <SA2PR10MB447446477FC9AC8335437D05F3099@SA2PR10MB4474.namprd10.prod.outlook.com> (raw)
In-Reply-To: <87k0mmouwq.fsf@gnus.org>

> > `define-minor-mode' do the following (or at least some of it):
> >
> > 1. Mention the mode variable (typically the same name as the mode,
> >    but in any case the name is known to `define-minor-mode').
> >    (The doc string currently mentions the keymap, but not the var.)
> 
> I've now done this in Emacs 28.
> 
> > 2. Show the current value of the variable, just as we do for the keymap.
> >    If undefined so far then say so, just as we do for the keymap.
> 
> I think that would be pretty odd -- it's just a function doc string,
> and the value of these variables in the *Help* buffer is usually nil.

Why do you think it would be odd?  It would be helpful.
The value reported would of course be for the buffer
where help was invoked - not for `*Help*' (unless it
was invoked there).

That's the way `*Help*' works and has always worked.
`C-h k <whatever>' doesn't tell you the binding in
`*Help*'.  I'm surprised to see this kind of argument
for not documenting something.

> > 3. Say whether the variable is global (an option, customizable), or
> >    buffer-local.
> 
> For minor modes?  No, I think that would be counter-productive -- minor
> modes should be toggled with the minor mode command.

Regardless of your last phrase, which is true in general
(but not always), a globalized minor mode DOES create
a user option - customizable.  Ask yourself why.  Help
should tell users about it when that's the case.

Users shouldn't have to consult the doc for
`define-minor-mode' and `define-globalized-minor-mode'
each time they ask for help on a minor mode.  That's
been the problem from the outset, and it's still a
problem to some extent.

> And besides -- the "mode variable" isn't necessarily a variable:

No, not necessarily.  All the more reason for Help to
tell you what it is.  It should tell you when it's a
user option, a normal defvar, and a generalized var.

> The useful thing, I think, is to have the doc string
> document the getter "variable", 

There is no one "useful thing".  Certainly documenting
the variable (generalized or not) is important, and
it's only one of the things that's important.

> so that you know how to check whether the mode is
> off or on.

Help on the mode should also do that - see the first
thing, above.  Knowing what the variable is is good.
Knowing what the current state is is good.  Help on
a minor mode should tell you all such things.

> so I'm closing this bug report.)

Too bad.  But at least you presumably made some of
the suggested improvements.

> > 4. Maybe mention that the variable is set/reset automatically when you
> >    toggle the mode.  If the var is global mention that you can set/reset
> >    it manually using Customize.
> 
> Ditto.

Dunno what "ditto" means here.  There was some that
you did and much that you didn't do.  Whether you
did #4 isn't clear (without digging out the new code).





      reply	other threads:[~2021-06-22 15:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-04 15:19 bug#36500: 26.2; Minor mode doc strings - say what the current mode-variable value is Drew Adams
2019-07-08 20:42 ` Lars Ingebrigtsen
2019-07-08 21:26   ` Drew Adams
2021-06-22 14:07 ` Lars Ingebrigtsen
2021-06-22 15:10   ` Drew Adams [this message]

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=SA2PR10MB447446477FC9AC8335437D05F3099@SA2PR10MB4474.namprd10.prod.outlook.com \
    --to=drew.adams@oracle.com \
    --cc=36500@debbugs.gnu.org \
    --cc=larsi@gnus.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.
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).