[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Should mode commands be idempotent?
From: |
Drew Adams |
Subject: |
RE: Should mode commands be idempotent? |
Date: |
Tue, 26 Sep 2017 10:55:28 -0700 (PDT) |
> FWIW, I can't off the top of my head think of a reason why
> (foo-mode 1) followed by (foo-mode 1) should do something
> different than just calling it once.
Just what do you have in mind, for the meaning here of
"do something different"? Are we saying that the state
of the Emacs session after the second call should be
identical to the state after the first call? Just what
kind of "identical" would be meant?
As I said:
Beyond that, just what kind of "idempotence" is
in view? What program state do we expect must be
identical if a mode is turned on more than once?
And what do we mean by "identical" here?
Are we proposing a rule that a mode should not
establish any state that can be preserved and
updated each time the mode is turned on? Or are
we proposing something much less than that?
"Idempotence" is a big word. Just what do folks
have in mind for it, for the proposed rule?
(No answer to that, except from RMS, who said it
doesn't matter. In which case the rule doesn't mean
anything either. Anyone can claim "idempotence" for
any code, for some meaning of "idempotence" or
"identical". A guideline of "Be idempotent!" with
no explanation is useless.)
Would you argue, for example, that `foo-mode'
should not be allowed to count how many invocations
in a row it has had? (Why?)
A silly example, perhaps. The point is that:
1. Such a rule is not needed. We've all agreed
that it is _already_ generally respected, in any
usual sense. We haven't seen examples of why
the rule is needed - what we hope to gain by it.
No one has pointed to an existing mode that is
_intentionally_ non-idempotent, i.e., that feels
it needs to do something different for subsequent
turn-ons.
The only example given of a mode that does
something different was `visual-line-mode', where
it was agreed that the behavior is a bug and is
not intended or needed for the mode.
2. If such a rule were really needed then we'd need
to say what we mean by it: just what kinds of
state change are allowed for subsequent mode
turn-ons. Or else we'd need to claim that _no_
changes are allowed, something that is virtually
impossible to achieve, let alone verify.
I haven't seen a lot of motivation given for this
purported rule. But please try putting it into
English, so we can see what's really being proposed.
If it is just something like "Make sure your mode
is idempotent" then see above, both #1 and #2.
- RE: Should mode commands be idempotent?, (continued)
- Re: Should mode commands be idempotent?, Clément Pit-Claudel, 2017/09/23
- RE: Should mode commands be idempotent?, Drew Adams, 2017/09/24
- Re: Should mode commands be idempotent?, Clément Pit-Claudel, 2017/09/25
- RE: Should mode commands be idempotent?, Drew Adams, 2017/09/25
- Re: Should mode commands be idempotent?, Stefan Monnier, 2017/09/25
- Re: Should mode commands be idempotent?, John Wiegley, 2017/09/25
- RE: Should mode commands be idempotent?,
Drew Adams <=
- Re: Should mode commands be idempotent?, John Wiegley, 2017/09/26
- RE: Should mode commands be idempotent?, Drew Adams, 2017/09/26
- Re: Should mode commands be idempotent?, John Wiegley, 2017/09/26
Re: Should mode commands be idempotent?, John Wiegley, 2017/09/19
Re: Should mode commands be idempotent?, Richard Stallman, 2017/09/20