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.