RE: Should mode commands be idempotent?

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

> > > Users expect major modes to be idempotent.  Any time one is not, it
> > > will cause them surprises.  We should treat that as a bug and fix it
> > > to be idempotent.
> >
> > Yes. You're talking about code distributed with Emacs, no doubt.
> >
> > And any 3rd-party library (if there were any) that might have
> > such a mode function would be well advised to make clear to its
> > users that the function is not idempotent, and explain why:
> > what to expect and why.
> 
> I think that approach isn't strong enough to give users predictable
> behavior.  We should say that all major modes and minor modes are
> idempotent; then, if any fails to be, it will clearly be a bug.

1. Are you talking about a convention only for code
distributed with Emacs?  If so, see above.  It's fine for
Emacs Dev to consider that a bug.  An author/maintainer has
every right to define what "bug" means for their software.

But I think at least some here are talking about a
convention for Emacs _users_ to follow, e.g., for
3rd-party code, not just for code distributed with Emacs.

In that case, I don't see it as appropriate for an Emacs
convention to call out what constitutes a bug.

Certainly, some 3rd-party code might not _intend_ to have
a non-idempotent mode.  And in that case, the maintainer
might well prefer to fix that unintentional behavior, as
a bug.

(Some code that tests a mode and lets an author know that it
is in some way not idempotent could be useful in that case.)

But the rule being discussed seems to go beyond saying
only that if your mode doesn't _intend_ to be
non-idempotent then you might want to consider making it
idempotent.  We seem to be on the verge of prescribing
non-idempotence as a no-no.


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

In general it means that an operation "can be applied
multiple times without changing the result beyond the
initial application" (Wikipedia).

Just what do you have in mind wrt what is meant by the
"result" in this context?  Program state has lots of
aspects that can be affected by Lisp code, including
code that turns on a mode.

Which parts of the state of an Emacs session - and its
persistent context (e.g, disk files, websites,...) -
would you allow to be changed, i.e., to _not_ be
considered as part of the "result" of turning on a
mode, without violating your idempotence rule?