unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Eli Zaretskii <eliz@gnu.org>, Drew Adams <drew.adams@oracle.com>
Cc: rms@gnu.org, 32643@debbugs.gnu.org
Subject: bug#32643: 26; minor-mode variables
Date: Fri, 7 Sep 2018 08:07:49 -0700 (PDT)	[thread overview]
Message-ID: <76891a81-fd9d-4a8d-aa34-a653e39b8276@default> (raw)
In-Reply-To: <<83lg8dvmia.fsf@gnu.org>>

> > > As for auto-fill-mode, can you tell why it is important to have a
> > > variable there?  What cannot you do without that variable?
> >
> > No, according to the convention the shoe is on the other foot.
> > Why should it not have a variable? That's the convention.
> > Why should `auto-fill-mode' be an exception?
> 
> Because it always was like that.

You can't even say why it was made an exception to the rule,
yet you say that it should remain such an exception just because
it was one. Amazing.

It would be one thing, if you pointed out some possible reasons
why any variable should be an exception. To just say that we
don't know why it is the way it is but it should remain a rule
breaker for unknown reasons is quite a stance.

> > You can do `C-h v auto-fill-mode' to check whether it is on.
> > Minor modes do not necessarily have mode-line lighters.
> 
> But auto-fill-mode does have a lighter.

The point is that you cannot depend on a lighter for this in
general, because "Minor modes do not necessarily have
mode-line lighters."

And even in the case of one, like auto-fill-mode, which does
have a lighter, if you don't know that it does and the mode
is off then you won't necessarily think to try toggling it twice
and look for the lighter.

But `C-h v VARIABLE' works every time - as long as the mode
has a variable. And there are, I think, far, far fewer modes
that don't have variables than modes that don't have lighters.
(No, I have no proof of that. But do you think otherwise?)

> > > > > I think the manual already does what you want, it just doesn't say
> > > > > this is a bug (because it isn't, IMO).
> > > >
> > > > The manual says nothing, AFAICT, that provides guidance about when
> > > > a mode should not or need not have a variable. Based on what it does
> > > > say, each mode "should" have a variable. Is that your point?
> > >
> > > My point is that the manual recommends that there be a variable.
> >
> > No one disagrees that that is the case.
> 
> Then you agree that "the manual already does what you want", yes?

No. And I've been clear about what's missing or misleading. I won't
repeat that unless it is unclear to you even after rereading what I've
already said about it.

> > > > Keeping the text suggests that there is some good reason why some
> > > > modes do not have variables.
> > >
> > > There's no such suggestion, it's just a statement of a fact.
> >
> > Why is that fact stated?
> 
> OK, I think this discussion goes nowhere, so let's stop here.





      parent reply	other threads:[~2018-09-07 15:07 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-05 15:13 bug#32643: 26; minor-mode variables Drew Adams
2018-09-06  5:51 ` Richard Stallman
2018-09-06 14:18   ` Drew Adams
2018-09-06 14:33     ` Eli Zaretskii
2018-09-08  2:07     ` Noam Postavsky
2018-09-08  2:25       ` Drew Adams
2018-09-09 20:33         ` Noam Postavsky
2018-09-09 22:09           ` Drew Adams
2018-09-12  0:51             ` Noam Postavsky
2018-09-12  1:46               ` Drew Adams
2018-09-13  3:32               ` Richard Stallman
2018-09-13 13:28                 ` Basil L. Contovounesios
2018-09-09  6:05       ` Richard Stallman
2018-09-09 14:12         ` Drew Adams
2018-09-10  7:27           ` Andreas Röhler
     [not found]   ` <<494224f1-815f-4fb4-a779-75e243b519f0@default>
     [not found]     ` <<83sh2mwv8w.fsf@gnu.org>
2018-09-06 14:51       ` Drew Adams
2018-09-06 18:35         ` Eli Zaretskii
     [not found]   ` <<<494224f1-815f-4fb4-a779-75e243b519f0@default>
     [not found]     ` <<<83sh2mwv8w.fsf@gnu.org>
     [not found]       ` <<488f04e4-8389-459b-b3c7-603e48bed452@default>
     [not found]         ` <<83lg8ewk2c.fsf@gnu.org>
2018-09-07  0:10           ` Drew Adams
2018-09-07  6:40             ` Eli Zaretskii
2018-09-08  5:13             ` Richard Stallman
2018-09-08 13:58               ` Drew Adams
2018-09-08 17:53                 ` Andreas Röhler
     [not found]   ` <<<<494224f1-815f-4fb4-a779-75e243b519f0@default>
     [not found]     ` <<<<83sh2mwv8w.fsf@gnu.org>
     [not found]       ` <<<488f04e4-8389-459b-b3c7-603e48bed452@default>
     [not found]         ` <<<83lg8ewk2c.fsf@gnu.org>
     [not found]           ` <<fb9c0be1-c9da-4cf8-aab3-fd54a0a97e68@default>
     [not found]             ` <<83lg8dvmia.fsf@gnu.org>
2018-09-07 15:07               ` 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=76891a81-fd9d-4a8d-aa34-a653e39b8276@default \
    --to=drew.adams@oracle.com \
    --cc=32643@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=rms@gnu.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).