From: Drew Adams <drew.adams@oracle.com>
To: Noam Postavsky <npostavs@gmail.com>
Cc: rms@gnu.org, 32643@debbugs.gnu.org
Subject: bug#32643: 26; minor-mode variables
Date: Sun, 9 Sep 2018 15:09:55 -0700 (PDT) [thread overview]
Message-ID: <c6f0245b-23f7-4ad2-bcb9-ec50109ba43b@default> (raw)
In-Reply-To: <87worufm2e.fsf@gmail.com>
> >> 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.
next prev parent reply other threads:[~2018-09-09 22:09 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 [this message]
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
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c6f0245b-23f7-4ad2-bcb9-ec50109ba43b@default \
--to=drew.adams@oracle.com \
--cc=32643@debbugs.gnu.org \
--cc=npostavs@gmail.com \
--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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.