RE: Should mode commands be idempotent?

[Drew Adams <drew.adams@oracle.com>]

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