bug#32643: 26; minor-mode variables

bug#32643: 26; minor-mode variables

[Drew Adams]

(emacs) `Minor Modes' says "Most minor modes also have a "mode 
variable", with the same name as the mode command."

It doesn't say why some do and some don't.  Why doesn't it?  What's the
answer to that question?  For example, why doesn't variable
`auto-fill-mode' exist?  Shouldn't all minor modes have a variable?
Which ones should?

Beyond the Emacs manual, (elisp) `Minor Mode Conventions' says this:

  Define a variable whose name ends in '-mode'.  We call this the
  "mode variable".  The minor mode command should set this variable.
  The value will be 'nil' if the mode is disabled, and non-'nil' if
  the mode is enabled.  The variable should be buffer-local if the
  minor mode is buffer-local.

  This variable is used in conjunction with the 'minor-mode-alist' to
  display the minor mode name in the mode line.  It also determines
  whether the minor mode keymap is active, via 'minor-mode-map-alist'
  (*note Controlling Active Maps::).  Individual commands or hooks
  can also check its value.

That says that, by convention, minor modes ahould have a variable.
Isn't it then a bug that some provided by Emacs do not?  And shouldn't
the Elisp manual (and perhaps the Emacs manual) give criteria for when a
minor mode should probably not have a variable?

What's more, the same node about conventions says this:

  Define a command, called the "mode command", whose name is the same
  as the mode variable.  Its job is to set the value of the mode
  variable, plus anything else that needs to be done to actually
  enable or disable the mode's features.

That suggests that the primary job of the mode command is to set the
mode variable.  This suggests strongly that it is a bug not to have a
mode variable.

In GNU Emacs 26.1 (build 1, x86_64-w64-mingw32)
 of 2018-05-30
Repository revision: 07f8f9bc5a51f5aa94eb099f3e15fbe0c20ea1ea
Windowing system distributor `Microsoft Corp.', version 10.0.16299
Configured using:
 `configure --without-dbus --host=x86_64-w64-mingw32
 --without-compress-install 'CFLAGS=-O2 -static -g3''

bug#32643: 26; minor-mode variables

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > It doesn't say why some do and some don't.  Why doesn't it?  What's the
  > answer to that question?  For example, why doesn't variable
  > `auto-fill-mode' exist?  Shouldn't all minor modes have a variable?
  > Which ones should?

It is not crucial for the manual to answer "why" questions.
If this one were easy to answer, it could be worth answering.
But in fact this one would be a lot of work.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#32643: 26; minor-mode variables

[Drew Adams]

>   > It doesn't say why some do and some don't.  Why doesn't it?  What's the
>   > answer to that question?  For example, why doesn't variable
>   > `auto-fill-mode' exist?  Shouldn't all minor modes have a variable?
>   > Which ones should?
> 
> It is not crucial for the manual to answer "why" questions.
> If this one were easy to answer, it could be worth answering.
> But in fact this one would be a lot of work.

I get that you replied only about that intro paragraph. And no,
it's not "crucial" to explain "why" about everything. Far from it.

And I guess you're only speaking against any blanket requirement
to explain "why" everywhere, and not against a request that
`auto-fill-mode' have a variable etc.

But the real point of the bug report is that we _do_ say that a
minor mode should have (and set) a mode variable:

  Define a variable whose name ends in '-mode'.  We call this the
  "mode variable".  The minor mode command should set this
  variable.

And that "should" is not respected by some variables from basic
Emacs itself - in particular `auto-fill-mode'. Shouldn't it be?

Nothing requires everything in the Emacs distribution to respect
each convention that Emacs sets forth. But is there a reason why
`auto-fill-mode' (and others?) should not respect this convention?
If nothing else, I'm curious why the exception(s).

(The bug report also asks whether it's a bug for a mode not to have
a variable, and suggests that it is. And if it's not, the report asks that
the Elisp manual give some guidance about when a mode should
not or need not have a variable.)

bug#32643: 26; minor-mode variables

[Eli Zaretskii]

> Date: Thu, 6 Sep 2018 07:18:45 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 32643@debbugs.gnu.org
> 
> But the real point of the bug report is that we _do_ say that a
> minor mode should have (and set) a mode variable:
> 
>   Define a variable whose name ends in '-mode'.  We call this the
>   "mode variable".  The minor mode command should set this
>   variable.
> 
> And that "should" is not respected by some variables from basic
> Emacs itself - in particular `auto-fill-mode'. Shouldn't it be?

FWIW, I see no need to demand 100% consistency here.

> Nothing requires everything in the Emacs distribution to respect
> each convention that Emacs sets forth. But is there a reason why
> `auto-fill-mode' (and others?) should not respect this convention?
> If nothing else, I'm curious why the exception(s).

Most probably, historical accidents.  But even finding that out is a
non-trivial amount of work.

> (The bug report also asks whether it's a bug for a mode not to have
> a variable, and suggests that it is. And if it's not, the report asks that
> the Elisp manual give some guidance about when a mode should
> not or need not have a variable.)

I think the manual already does what you want, it just doesn't say
this is a bug (because it isn't, IMO).

bug#32643: 26; minor-mode variables

[Noam Postavsky]

Drew Adams <drew.adams@oracle.com> writes:

> And that "should" is not respected by some variables from basic
> Emacs itself - in particular `auto-fill-mode'. Shouldn't it be?
>
> Nothing requires everything in the Emacs distribution to respect
> each convention that Emacs sets forth. But is there a reason why
> `auto-fill-mode' (and others?) should not respect this convention?
> If nothing else, I'm curious why the exception(s).

Applying common sense, the obvious explanation is that auto-fill-mode
controls only a single variable (i.e., `auto-fill-function'), and adding
an extra `auto-fill-mode' which would then have to be kept in sync just
to conform to some convention is not worth the trouble.

> (The bug report also asks whether it's a bug for a mode not to have
> a variable, and suggests that it is. And if it's not, the report asks that
> the Elisp manual give some guidance about when a mode should
> not or need not have a variable.)

I don't think the Elisp manual needs to fill in for user's common sense
by telling them they are free to break conventions if it makes sense to
do so.  The fact that it's a "convention" and not a "requirement" should
be enough.

bug#32643: 26; minor-mode variables

[Drew Adams]

> > And that "should" is not respected by some variables from basic
> > Emacs itself - in particular `auto-fill-mode'. Shouldn't it be?
> >
> > Nothing requires everything in the Emacs distribution to respect
> > each convention that Emacs sets forth. But is there a reason why
> > `auto-fill-mode' (and others?) should not respect this convention?
> > If nothing else, I'm curious why the exception(s).
> 
> Applying common sense, the obvious explanation is that auto-fill-mode
> controls only a single variable (i.e., `auto-fill-function'), and adding
> an extra `auto-fill-mode' which would then have to be kept in sync just
> to conform to some convention is not worth the trouble.

Thanks. It may be obvious to someone looking at the code, but
it's not obvious to someone (or some code) that looks only for
mode variable `auto-fill-mode'.

But yes, in this case it is apparently not a historical accident that
there is no `auto-fill-mode' variable. And the doc string does
helpfully say that you can look at that other variable instead.
(Code looking only for the expected mode variable won't see
that, but a person can.)

> > (The bug report also asks whether it's a bug for a mode not to have
> > a variable, and suggests that it is. And if it's not, the report asks that
> > the Elisp manual give some guidance about when a mode should
> > not or need not have a variable.)
> 
> I don't think the Elisp manual needs to fill in for user's common sense
> by telling them they are free to break conventions if it makes sense to
> do so.  The fact that it's a "convention" and not a "requirement" should
> be enough.

It's not about users being free to break the convention - that's of
course the case, for all Emacs conventions. It's about having some
idea (see above) of when it might "make sense to do so".

That users are free to not follow an Elisp coding convention is
something different from whether and how much the distributed
Emacs Lisp code should do so. The bug report is not about whether
some user code should follow the convention - you twisted that
around.

bug#32643: 26; minor-mode variables

[Noam Postavsky]

Drew Adams <drew.adams@oracle.com> writes:

> (Code looking only for the expected mode variable won't see
> that, but a person can.)

If someone sends a fix for Bug#29081, then code will be able to figure
out where to look as well.

>> > (The bug report also asks whether it's a bug for a mode not to have
>> > a variable, and suggests that it is. And if it's not, the report asks that
>> > the Elisp manual give some guidance about when a mode should
>> > not or need not have a variable.)
>> 
>> I don't think the Elisp manual needs to fill in for user's common sense
>> by telling them they are free to break conventions if it makes sense to
>> do so.  The fact that it's a "convention" and not a "requirement" should
>> be enough.
>
> It's not about users being free to break the convention - that's of
> course the case, for all Emacs conventions. It's about having some
> idea (see above) of when it might "make sense to do so".
>
> That users are free to not follow an Elisp coding convention is
> something different from whether and how much the distributed Emacs
> Lisp code should do so.  The bug report is not about whether some user
> code should follow the convention

Okay, so I don't think the Emacs manual needs to fill in for user's
common sense by telling them that Emacs breaks conventions if it makes
sense to do so.  The fact that it's a "convention" and not a
"requirement" should be enough.

> - you twisted that around.

Did I?  From my end, it looks like you had some idle question about the
implementation of auto-fill-mode, and instead of looking at the source
for 5 minutes, you sent a long and rambling bug report.

Then, you got 3 responses, none of which exactly matched what you were
trying to say.  You respond with more rambling, argumentation, and
accusation.

Given your posting history, am I surprised that you rudely abuse the bug
list in this way?  No.  But I'm not happy about it either.

bug#32643: 26; minor-mode variables

[Drew Adams]

> >> I don't think the Elisp manual needs to fill in for user's common sense
> >> by telling them they are free to break conventions if it makes sense to
> >> do so.  The fact that it's a "convention" and not a "requirement" should
> >> be enough.
> >
> > It's not about users being free to break the convention - that's of
> > course the case, for all Emacs conventions. It's about having some
> > idea (see above) of when it might "make sense to do so".
> >
> > That users are free to not follow an Elisp coding convention is
> > something different from whether and how much the distributed Emacs
> > Lisp code should do so.  The bug report is not about whether some user
> > code should follow the convention
> 
> Okay, so I don't think the Emacs manual needs to fill in for user's
> common sense by telling them that Emacs breaks conventions if it
> makes sense to do so.  The fact that it's a "convention" and not a
> "requirement" should be enough.

Why should someone assume that a given (distributed Emacs code)
departure from a convention is intended and not just a "historical
accident" or a bug for some other reason? Why shouldn't they
wonder, in the absence of any info, why this or that mode has no
variable? Saying that such a user just lacks common sense seems
a bit insulting, no?

Departure from a promoted convention puts the convention in
doubt, at least for the scope of that particular departure.

And in the case of `auto-fill-mode' it's not straightforward for a
user (at least this user, and apparently Eli also) to tell whether
the convention was not followed for a good reason, a bad
reason, or no reason (accident).

For Eli it was just a historical accident (probably). And what for
you should have been a matter of "looking at the source for 5
minutes" was guessed by Eli to amount to a "non-trivial amount
of work".

I admit that I didn't try to figure out why there was no such
variable by digging into the implementation. I thought it was
enough to raise the question of non-respect of the convention.

And yes, it was a _question_ - from the outset:

   It doesn't say why some do and some don't.  Why doesn't it? 
   What's the answer to that question?  For example, why
   doesn't variable `auto-fill-mode' exist?  Shouldn't all minor
   modes have a variable? Which ones should?

Those questions occurred to me when reading the manual.
I think they might occur to some other readers too.

So far I 've learned, since asking that, that one reason might
be the use of `:variable' - though it's still not clear to me why
that should preclude also having and syncing a normal mode
variable. Thank you for pointing out the use of `:variable'.

Other than that reason, it's been said that some modes don't
have variables probably just due to historical accident.

Both of those pieces of info are useful (to me, at least).

> > - you twisted that around.
> 
> Did I? 

I think you did. But I didn't mean that you were trying to do
something nasty. I figured you did that by misunderstanding.

The report is about whether and how much the distributed
Lisp code should follow its convention. You replied saying that
the manual doesn't need to tell users that they are free not to
follow conventions.

That wasn't the point. I never asked that the manual tell users
they are free not to follow conventions. It's not about users
following convention; it's about Emacs doing so.

Would it help users for the manual to say that due to
historical accident some modes don't have variables? I think
it might, but I wouldn't insist on adding that.

Would it help to say something about alternative mode
variables and `:variable'? I think it would, but probably only
in the Elisp manual.

Would it help to come up with an easy way to sync a mode
variable with an alternative (e.g. `:variable') variable? I think
it might, but I don't have code for that.

> From my end, it looks like you had some idle question about the
> implementation of auto-fill-mode, and instead of looking at the source
> for 5 minutes, you sent a long and rambling bug report.

What's your aim, there?

I didn't have an idle question about implementation. As a user
I felt that (as Andreas seconded) the mode variable can be a
useful "way to check if the mode is on". That's how I discovered
that there was no standard variable for `auto-fill-mode': `C-h v'.

The report is not about that particular variable, though I did
(and still do) wonder whether it might be handled better.

I thought that was clear from the outset. I hope it's clear now.

As for the "long and rambling bug report": the report is 11 short
lines, not counting text from the manuals. Sorry if it took too
much of your time. Perhaps you'll prefer to skip my reports
from now on. That would be unfortunate for me (and maybe
for Emacs), as your attention has consistently been helpful
(including for this report).

> Then, you got 3 responses, none of which exactly matched
> what you were trying to say. 

No idea what you are trying to say there, by matching etc.

Anyway, I believe I received only one response (from RMS),
to which I replied.

Then there were replies to that reply, and so on. Altogether
there were 9 replies to my mails, and I wrote 7 replies (now
8) plus the report.

> You respond with more rambling, argumentation, and
> accusation.

I don't think so. But I did present and reply to arguments.

> Given your posting history, am I surprised that you rudely abuse
> the bug list in this way?  No.  But I'm not happy about it either.

Sorry you feel that way. Please point out what you think was
rude, abusive, and accusative on my part. I hope to avoid
prompting such a response in the future. Thanks.

bug#32643: 26; minor-mode variables

[Noam Postavsky]

Drew Adams <drew.adams@oracle.com> writes:

> So far I 've learned, since asking that, that one reason might
> be the use of `:variable' - though it's still not clear to me why
> that should preclude also having and syncing a normal mode
> variable.

No, that's putting the card before the horse.  I meant rather that the
cost of having two variables and keeping them in sync would outweigh the
benefit of following the convention.  Using :variable is just the way to
implement having only a single variable, it's not a reason for avoiding
a second variable.

>> > - you twisted that around.
>> 
>> Did I? 
>
> I think you did. But I didn't mean that you were trying to do
> something nasty. I figured you did that by misunderstanding.

Okay, I got a bit frustrated at seeing you fill up yet another bug
thread with some kind of argument over... something (I can't even tell
what exactly).  So I was feeling a bit predisposed to read things in a
hostile tone.

And my response was hostile too, sorry.

>> Given your posting history, am I surprised that you rudely abuse
>> the bug list in this way?  No.  But I'm not happy about it either.
>
> Sorry you feel that way. Please point out what you think was
> rude, abusive, and accusative on my part. I hope to avoid
> prompting such a response in the future. Thanks.

So, your original report here was mostly okay.  It was a bit vague
though, I think a few concrete phrasing proposals would have helped to
anchor it a bit better and prevent the subsequent derailing.

You do generally have a tendency to send long messages which could be
summarized into a couple of sentences.  And also to interject into
discussions without reading all of the previous messages.  I get that
discussion can get long and it's hard to keep up, but by sending your
(long and possibly irrelevant due to not having read the context)
message you make that same problem worse for everyone else.

I do consider those things disrepectful and somewhat rude, I think my
low-level annoyance about it bleeds into my reading of your other
messages even when you're not specifically doing that.

bug#32643: 26; minor-mode variables

[Drew Adams]

> Okay, I got a bit frustrated at seeing you fill up yet another bug
> thread with some kind of argument over... something (I can't even tell
> what exactly).  So I was feeling a bit predisposed to read things in a
> hostile tone. And my response was hostile too, sorry.

Thanks for that. You are among the least hostile, and least easy
to mistake for being hostile, people here. Feel good about that.

> So, your original report here was mostly okay.  It was a bit vague
> though, I think a few concrete phrasing proposals would have helped to
> anchor it a bit better and prevent the subsequent derailing.
> 
> You do generally have a tendency to send long messages which could be
> summarized into a couple of sentences.  And also to interject into
> discussions without reading all of the previous messages.  I get that
> discussion can get long and it's hard to keep up, but by sending your
> (long and possibly irrelevant due to not having read the context)
> message you make that same problem worse for everyone else.

I see.

> I do consider those things disrepectful and somewhat rude, I think my
> low-level annoyance about it bleeds into my reading of your other
> messages even when you're not specifically doing that.

Thanks for sharing your thoughts sincerely.

bug#32643: 26; minor-mode variables

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > No, that's putting the card before the horse.

Amusing idea.  What do horses do with cards?
Eat them?
Scan them and put charges on them?

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#32643: 26; minor-mode variables

[Basil L. Contovounesios]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > No, that's putting the card before the horse.
>
> Amusing idea.  What do horses do with cards?
> Eat them?
> Scan them and put charges on them?

They use them as horseplaying cards, of course.

-- 
Basil

bug#32643: 26; minor-mode variables

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Applying common sense, the obvious explanation is that auto-fill-mode
  > controls only a single variable (i.e., `auto-fill-function'), and adding
  > an extra `auto-fill-mode' which would then have to be kept in sync just
  > to conform to some convention is not worth the trouble.

We could arrange for Auto-Fill mode to be controlled by a variable
auto-fill-mode.  Change the auto-fill code so that two variables
control it: (and auto-fill-mode auto-fill-function (funcall
auto-fill-function ...)).  Then we could leave auto-fill-function set
up all the time, and enable/disable the mode by setting auto-fill-mode
as with most other minor modes.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#32643: 26; minor-mode variables

[Drew Adams]

>   > Applying common sense, the obvious explanation is that auto-fill-mode
>   > controls only a single variable (i.e., `auto-fill-function'), and adding
>   > an extra `auto-fill-mode' which would then have to be kept in sync just
>   > to conform to some convention is not worth the trouble.
> 
> We could arrange for Auto-Fill mode to be controlled by a variable
> auto-fill-mode.  Change the auto-fill code so that two variables
> control it: (and auto-fill-mode auto-fill-function (funcall
> auto-fill-function ...)).  Then we could leave auto-fill-function set
> up all the time, and enable/disable the mode by setting auto-fill-mode
> as with most other minor modes.

I do hope that someone does something, perhaps along those lines,
to provide an `auto-fill-mode' variable.

As I said, I'm not familiar with the `:variable' stuff. I'd think that using
`:set' would be sufficient, to ensure that both variables are updated
correctly whenever `auto-fill-mode' is set. But perhaps that would
not suffice to ensure that whenever `auto-fill-function' is set.

(A guess is that using `:variable' provides a simpler or more elegant
way of doing what could be done using `:set'.)

bug#32643: 26; minor-mode variables

[Andreas Röhler]

On 09.09.2018 16:12, Drew Adams wrote:
>>    > Applying common sense, the obvious explanation is that auto-fill-mode
>>    > controls only a single variable (i.e., `auto-fill-function'), and adding
>>    > an extra `auto-fill-mode' which would then have to be kept in sync just
>>    > to conform to some convention is not worth the trouble.
>>
>> We could arrange for Auto-Fill mode to be controlled by a variable
>> auto-fill-mode.  Change the auto-fill code so that two variables
>> control it: (and auto-fill-mode auto-fill-function (funcall
>> auto-fill-function ...)).  Then we could leave auto-fill-function set
>> up all the time, and enable/disable the mode by setting auto-fill-mode
>> as with most other minor modes.
> 
> I do hope that someone does something, perhaps along those lines,
> to provide an `auto-fill-mode' variable.
> 
> As I said, I'm not familiar with the `:variable' stuff. I'd think that using
> `:set' would be sufficient, to ensure that both variables are updated
> correctly whenever `auto-fill-mode' is set. But perhaps that would
> not suffice to ensure that whenever `auto-fill-function' is set.
> 
> (A guess is that using `:variable' provides a simpler or more elegant
> way of doing what could be done using `:set'.)
> 
> 
> 

Maybe that can be done by defmacro define-minor-mode already - no need 
for hand-writing?

bug#32643: 26; minor-mode variables

[Drew Adams]

> Most probably, historical accidents.  But even finding that out is a
> non-trivial amount of work.

`auto-fill-mode' has already been identified. Let this bug report serve
(at least) to ask that Emacs set an `auto-fill-mode' mode variable.

> > (The bug report also asks whether it's a bug for a mode not to have
> > a variable, and suggests that it is. And if it's not, the report asks that
> > the Elisp manual give some guidance about when a mode should
> > not or need not have a variable.)
> 
> 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?

In that case, perhaps we should remove the text about some existing
modes not respecting this "should" - especially if that is only by
historical accident. Keeping the text suggests that there is some good
reason why some modes do not have variables.

And since a mode not having a variable is likely only an accident, 
presumably such a mode "should" be fixed, if identified.

Your point is presumably that there is no need to go searching for
such problems to fix, and it's not the end of the world if some such
modes exist. With that I agree.

Arguing about whether non-respect by Emacs code of some Emacs
convention is a "bug" is a bit like arguing about the number of
angels that can fit on a pinhead (poor Zippy!).

That's not the point of this bug report. I don't care whether you
call it a bug or "non-respect of the convention" or an enhancement
request.

bug#32643: 26; minor-mode variables

[Eli Zaretskii]

> Date: Thu, 6 Sep 2018 07:51:10 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: rms@gnu.org, 32643@debbugs.gnu.org
> 
> > Most probably, historical accidents.  But even finding that out is a
> > non-trivial amount of work.
> 
> `auto-fill-mode' has already been identified. Let this bug report serve
> (at least) to ask that Emacs set an `auto-fill-mode' mode variable.

You've changed the subject by eliding the context.  The above was an
answer to your question why some modes have variables while others
don't.

As for auto-fill-mode, can you tell why it is important to have a
variable there?  What cannot you do without that variable?

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

> In that case, perhaps we should remove the text about some existing
> modes not respecting this "should" - especially if that is only by
> historical accident.

If we remove that, we will have no way to respond to bug reports
requesting that all modes shall have a variable.

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

> And since a mode not having a variable is likely only an accident, 
> presumably such a mode "should" be fixed, if identified.

Not every accident deserves to be fixed.

bug#32643: 26; minor-mode variables

[Drew Adams]

> > > Most probably, historical accidents.  But even finding that out is a
> > > non-trivial amount of work.
> >
> > `auto-fill-mode' has already been identified. Let this bug report serve
> > (at least) to ask that Emacs set an `auto-fill-mode' mode variable.
> 
> You've changed the subject by eliding the context.  The above was an
> answer to your question why some modes have variables while others
> don't.

Yes, it was. And my redaction of the text just before it didn't
 change anything in that regard. If you think it did, please
elaborate.

> 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? The fact that
there are some exceptions is no argument for why `a-f-m'
should be one of them.

Plus, you're setting a high bar: you ask what is _impossible to
do_ without the variable. If you insist on putting the shoe on
my foot then the only somewhat reasonable question is how
might it be useful to have the variable - not what is impossible (!)
to do without it.

Anyway, if you insist on asking for a possible use... One answer
is the same as for any other variable:

You can do `C-h v auto-fill-mode' to check whether it is on.
Minor modes do not necessarily have mode-line lighters.
And even in a customized mode-line that shows no lighters that
will tell you whether the mode is on.

Again, why would you _not_ want to have such a variable?

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

> > In that case, perhaps we should remove the text about some existing
> > modes not respecting this "should" - especially if that is only by
> > historical accident.
> 
> If we remove that, we will have no way to respond to bug reports
> requesting that all modes shall have a variable.

Huh? Why can't you respond to such a report? Or do you think that
the manual stating only that some do and some don't provides an
excuse for doing nothing in that regard? That doesn't follow.

> > 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? Is it really to have a way to respond to
bug reports that ask to follow the convention, by saying that
the convention doesn't apply to some modes (without saying
which or why or...)? That's the only reason you've given, so far.

bug#32643: 26; minor-mode variables

[Eli Zaretskii]

> Date: Thu, 6 Sep 2018 17:10:09 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: rms@gnu.org, 32643@debbugs.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 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.

> > > > 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?

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

bug#32643: 26; minor-mode variables

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > No, according to the convention the shoe is on the other foot.
  > Why should it not have a variable
  > Why should `auto-fill-mode' be an exception?

Because it isn't straightforward to do that.

It may be possible with some work.
Would you like to write the change?


-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#32643: 26; minor-mode variables

[Drew Adams]

>   > Why should it not have a variable
>   > Why should `auto-fill-mode' be an exception?
> 
> Because it isn't straightforward to do that.
> 
> It may be possible with some work.
> Would you like to write the change?

Noam's message points out the use of :variable in defining this minor mode. I don't understand `define-minor-mode' and its :variable
enough to propose a simple fix. Maybe someone else does?

In this case, the PLACE value of `:variable PLACE' is this generalized
variable:

(auto-fill-function
  . (lambda (v) (setq auto-fill-function
       (if v normal-auto-fill-function))))

Is there a way, for example, to defvaralias `auto-fill-mode' to
`auto-fill-function' (or vice versa), so that that :variable value
would somehow have the effect of automatically keeping
`auto-fill-mode' updated to the same value? Or some other
wayt to easily accomplish the same thing?

If there is no straightforward way to get `auto-fill-mode' to
remain synced with `auto-fill-function', and if it's necessary
to have two separate variables, then OK, for this particular
variable.

As I said earlier, it's good that the doc string, at least, makes
clear that non-nil `auto-fill-function' means the mode is on.

The bug report is more general, asking generally about minor
modes that have no mode variable, and what reasons/criteria
there might be for such cases. This one apparently has a
reason - it is not just a "historical accident". Dunno whether
there are others that could just have their variables defined
with no complications.

bug#32643: 26; minor-mode variables

[Andreas Röhler]

On 08.09.2018 15:58, Drew Adams wrote:
>>    > Why should it not have a variable
>>    > Why should `auto-fill-mode' be an exception?
>>
>> Because it isn't straightforward to do that.
>>
>> It may be possible with some work.
>> Would you like to write the change?
> 
> Noam's message points out the use of :variable in defining this minor mode. I don't understand `define-minor-mode' and its :variable
> enough to propose a simple fix. Maybe someone else does?
> 
> In this case, the PLACE value of `:variable PLACE' is this generalized
> variable:
> 
> (auto-fill-function
>    . (lambda (v) (setq auto-fill-function
>         (if v normal-auto-fill-function))))
> 
> Is there a way, for example, to defvaralias `auto-fill-mode' to
> `auto-fill-function' (or vice versa), so that that :variable value
> would somehow have the effect of automatically keeping
> `auto-fill-mode' updated to the same value? Or some other
> wayt to easily accomplish the same thing?
> 
> If there is no straightforward way to get `auto-fill-mode' to
> remain synced with `auto-fill-function', and if it's necessary
> to have two separate variables, then OK, for this particular
> variable.
> 
> As I said earlier, it's good that the doc string, at least, makes
> clear that non-nil `auto-fill-function' means the mode is on.
> 
> The bug report is more general, asking generally about minor
> modes that have no mode variable, and what reasons/criteria
> there might be for such cases. This one apparently has a
> reason - it is not just a "historical accident". Dunno whether
> there are others that could just have their variables defined
> with no complications.
> 
> 
> 

AFAIU setting such a variable would be helpful in all cases. It would 
provide a consistent way to check if the mode is on.

bug#32643: 26; minor-mode variables

[Drew Adams]

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