Should mode commands be idempotent?

Should mode commands be idempotent?

[Philipp Stephani]

[-- Attachment #1: Type: text/plain, Size: 324 bytes --]

Hi,

I think it's generally expected that mode commands (both major and minor)
are reasonably idempotent, i.e. calling them twice should have the same
effects as calling them once (unless using 'toggle, of course). However, I
couldn't find this requirement in the manual, should it be added to the
"Modes" section?

Philipp

[-- Attachment #2: Type: text/html, Size: 416 bytes --]

Re: Should mode commands be idempotent?

[Clément Pit-Claudel]

On 2017-09-19 21:58, Philipp Stephani wrote:
> I think it's generally expected that mode commands (both major and minor) are reasonably idempotent, i.e. calling them twice should have the same effects as calling them once (unless using 'toggle, of course). However, I couldn't find this requirement in the manual, should it be added to the "Modes" section?

I was not aware of this convention :/

Is there a way inside of a minor mode to check if it was already enabled before the current call, short of having a second variable for that? Most modes I've seen just check whether they're enabled or disabled, and do something based on that:

(define-minor-mode foo-mode
  "Foo."
  :lighter " foo"
  (if foo-mode
      (foo-mode-enable)
    (foo-mode-disable)))

This is often not idempotent (see visual-line-mode for a concrete example).

Clément.

Re: Should mode commands be idempotent?

[Stefan Monnier]

> Is there a way inside of a minor mode to check if it was already
> enabled before the current call, short of having a second variable
> for that?

It shouldn't be needed: the idempotence should emerge naturally from the
way the code is written, rather than being the result of special tests
to detect that particular situation.


        Stefan

Re: Should mode commands be idempotent?

[Clément Pit-Claudel]

On 2017-09-20 00:29, Stefan Monnier wrote:
>> Is there a way inside of a minor mode to check if it was already
>> enabled before the current call, short of having a second variable
>> for that?
>
> It shouldn't be needed: the idempotence should emerge naturally from the
> way the code is written, rather than being the result of special tests
> to detect that particular situation.

I'm not too sure: take the example of visual-line-mode: how do you make that idempotent without explicitly checking whether the mode has already been activated?

Re: Should mode commands be idempotent?

[John Wiegley]

>>>>> "CP" == Clément Pit-Claudel <cpitclaudel@gmail.com> writes:

CP> I'm not too sure: take the example of visual-line-mode: how do you make
CP> that idempotent without explicitly checking whether the mode has already
CP> been activated?

Also, is there a motivation for introducing this new requirement, seeing as
how we've never had such a restriction in the past?

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Should mode commands be idempotent?

[Stefan Monnier]

> Also, is there a motivation for introducing this new requirement, seeing as
> how we've never had such a restriction in the past?

In the case of minor modes, I think a good implementation of a minor
mode should be idempotent, because it can easily happen that a minor
mode is enabled twice via different hooks, e.g.:

    (add-hook 'text-mode-hook #'visual-line-mode)
    (add-hook 'xml-mode-hook  #'visual-line-mode)

If you know that xml-mode runs text-mode-hook, you can drop the second
line, but it's good if the second line is just redundant rather
than harmful (after all, some people prefer xml-mode not to run
text-mode-hook).

For major modes, I don't know what is the intention exactly, because I'm
not sure exactly what kind of non-idempotence there is out there.
I think for major modes a more significant issue is to make sure that

    (with-temp-buffer (insert text) (funcall mode))

doesn't do anything undesirable (and currently, we're pretty far from
having such a guarantee, although we do have code like the above at
various places).


        Stefan

RE: Should mode commands be idempotent?

[Drew Adams]

> > Also, is there a motivation for introducing this new requirement, seeing
> > as how we've never had such a restriction in the past?
> 
> In the case of minor modes, I think a good implementation of a minor
> mode should be idempotent, because it can easily happen that a minor
> mode is enabled twice via different hooks, e.g.:
> 
>     (add-hook 'text-mode-hook #'visual-line-mode)
>     (add-hook 'xml-mode-hook  #'visual-line-mode)
> 
> If you know that xml-mode runs text-mode-hook, you can drop the second
> line, but it's good if the second line is just redundant rather
> than harmful (after all, some people prefer xml-mode not to run
> text-mode-hook).
> 
> For major modes, I don't know what is the intention exactly, because I'm
> not sure exactly what kind of non-idempotence there is out there.
> I think for major modes a more significant issue is to make sure that
> 
>     (with-temp-buffer (insert text) (funcall mode))
> 
> doesn't do anything undesirable (and currently, we're pretty far from
> having such a guarantee, although we do have code like the above at
> various places).

Those are good points.  What should not be taken for granted,
I think, is that enabling twice can have only harmful effects
if a mode is not idempotent.  Not being idempotent only means
that invoking it more than once does not have zero effect.
It does not follow that it has harmful effects.

That's my point, about not imposing a convention or a requirement
without a good reason.  Not that I have in mind some particular
good use case for "beneficial" effects of multiple invocations.
Just that more than one invocation does not necessarily imply
harm instead of benefit.

Re: Should mode commands be idempotent?

[Philipp Stephani]

[-- Attachment #1: Type: text/plain, Size: 766 bytes --]

John Wiegley <jwiegley@gmail.com> schrieb am Mi., 20. Sep. 2017 um
17:38 Uhr:

> >>>>> "CP" == Clément Pit-Claudel <cpitclaudel@gmail.com> writes:
>
> CP> I'm not too sure: take the example of visual-line-mode: how do you make
> CP> that idempotent without explicitly checking whether the mode has
> already
> CP> been activated?
>
> Also, is there a motivation for introducing this new requirement, seeing as
> how we've never had such a restriction in the past?
>

Some cases I've come across (for lsp-mode, which is currently not
idempotent):
- Enabling a minor mode in both a parent and a derived mode hook.
- Restoring buffers from the desktop file.
In such cases minor modes are activated twice, causing errors if they are
not idempotent.

[-- Attachment #2: Type: text/html, Size: 1182 bytes --]

Re: Should mode commands be idempotent?

[Stefan Monnier]

>> It shouldn't be needed: the idempotence should emerge naturally from the
>> way the code is written, rather than being the result of special tests
>> to detect that particular situation.
> I'm not too sure: take the example of visual-line-mode: how do you make that
> idempotent without explicitly checking whether the mode has already
> been activated?

In this case I'd typically do something like the patch below,


        Stefan


diff --git a/lisp/simple.el b/lisp/simple.el
index a3d1cc3864..ed0a29bbcc 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -7053,22 +7053,21 @@ visual-line-mode
   :lighter " Wrap"
   (if visual-line-mode
       (progn
-	(set (make-local-variable 'visual-line--saved-state) nil)
-	;; Save the local values of some variables, to be restored if
-	;; visual-line-mode is turned off.
-	(dolist (var '(line-move-visual truncate-lines
-		       truncate-partial-width-windows
-		       word-wrap fringe-indicator-alist))
-	  (if (local-variable-p var)
-	      (push (cons var (symbol-value var))
-		    visual-line--saved-state)))
+	(unless visual-line--saved-state
+	  ;; Save the local values of some variables, to be restored if
+	  ;; visual-line-mode is turned off.
+	  (dolist (var '(line-move-visual truncate-lines
+		         truncate-partial-width-windows
+		         word-wrap fringe-indicator-alist))
+	    (if (local-variable-p var)
+	        (push (cons var (symbol-value var))
+		      visual-line--saved-state))))
 	(set (make-local-variable 'line-move-visual) t)
 	(set (make-local-variable 'truncate-partial-width-windows) nil)
 	(setq truncate-lines nil
-	      word-wrap t
-	      fringe-indicator-alist
-	      (cons (cons 'continuation visual-line-fringe-indicators)
-		    fringe-indicator-alist)))
+	      word-wrap t)
+        (add-to-list 'fringe-indicator-alist
+                     (cons 'continuation visual-line-fringe-indicators)))
     (kill-local-variable 'line-move-visual)
     (kill-local-variable 'word-wrap)
     (kill-local-variable 'truncate-lines)

Re: Should mode commands be idempotent?

[Clément Pit-Claudel]

On 2017-09-21 00:25, Stefan Monnier wrote:
>>> It shouldn't be needed: the idempotence should emerge naturally from the
>>> way the code is written, rather than being the result of special tests
>>> to detect that particular situation.
>> I'm not too sure: take the example of visual-line-mode: how do you make that
>> idempotent without explicitly checking whether the mode has already
>> been activated?
> 
> In this case I'd typically do something like the patch below

Thanks. AFAICT visual-line--saved-state acts mostly as a proxy for checking whether the mode was enabled, but I also see that it's not quite the same as not running the mode function if it's already enabled.

Interestingly, what makes visual-line-mode not idempotent in the first place is that it goes to great lengths to save user settings and restore them.  Had it not done this (that is, had it just killed the local variable bindings when disabled), it would have been idempotent but more annoying to use.

It isn't even obvious that the current behavior (even with your patch) is what we want, anyway: what if I have another mode foo-mode that touches the same variables as visual-line-mode? Then I can run (visual-line-mode), (foo-mode), (visual-line-mode -1), and then which state should I be in?  There's a more general problem here, and it's not an easy one :/

Re: Should mode commands be idempotent?

[Stefan Monnier]

> It isn't even obvious that the current behavior (even with your patch) is
> what we want, anyway: what if I have another mode foo-mode that touches the
> same variables as visual-line-mode? Then I can run (visual-line-mode),
> (foo-mode), (visual-line-mode -1), and then which state should I be in?
> There's a more general problem here, and it's not an easy one :/

I know.  We need something along the same lines as add-function but for
arbitrary values rather than only for functions.  It was pretty close to
the top of my todo list recently (close enough that I thought about it,
but not close enough to get usable code out of it).


        Stefan

Re: Should mode commands be idempotent?

[Stefan Monnier]

> the top of my todo list recently (close enough that I thought about it,
> but not close enough to get usable code out of it).

I finally found the the pseudo-code I wrote for it back then, in case
you're interested (it was in my local nadvice.el hacks).  See below
(guaranteed 100% untested).


        Stefan


;;; Changing variables in general (not just function-valued ones)

;; TODO: Handle buffer-local settings!
;; TODO: Make it work for arbitrary gv-places?
;; TODO: Maybe use it or something similar to keep track of effects of
;;       loading a file (where `id' would be the file name)?

(defun advice--var-apply-op (val op v)
  (pcase-exhaustive op
    (:override v)
    (:around (funcall v val))))

(defun advice--var-compute-val (var)
  (let ((xs (get var 'advice-var-settings)))
    (if (not xs)
        (symbol-value var)
      (let ((val (car xs)))
        (pcase-dolist (`(,_id ,op ,v) (cdr xs))
          (setq val (advice--var-apply-op val op v)))
        val))))

(defun advice--var-set (var id op v)      ;TODO: add a `depth'?
  (let ((xs (get var 'advice-var-settings)))
    (unless xs
      (setq xs (list (symbol-value var)))
      (setf (get var 'advice-var-settings) xs))
    (unless (equal (symbol-value var)
                   (advice--var-compute-val var))
      (message "Var %S changed outside of `advice-set'" var))
    ;; FIXME: We could almost use
    ;;     (setf (alist-get id (cdr xs)) (list op v))
    ;; Except that we want to add new entries at the end!
    (let ((x (assoc id (cdr xs))))
      (if x
          ;; There's already another setting for `id'.
          (setcdr x (list op v))
        (setcdr (last xs) (list (list id op v)))))
    (set var (advice--var-compute-val var))))

(defun advice--var-unset (var id)
  (let* ((xs (get var 'advice-var-settings))
         (x (assoc id (cdr xs))))
    (when x
      (delq x xs)
      (set var (advice--var-compute-val var))
      (unless (cdr xs)
        (setf (get var 'advice-var-settings) nil)))))

RE: Should mode commands be idempotent?

[Drew Adams]

> I think it's generally expected that mode commands (both major and
> minor) are reasonably idempotent, i.e. calling them twice should
> have the same effects as calling them once (unless using 'toggle,
> of course).  However, I couldn't find this requirement in the manual,
> should it be added to the "Modes" section?

It is perhaps typical; i.e., perhaps most modes have that
property.  But I don't see why it "should" be true of modes.
Why should it be a "requirement" or a convention?

People can use a mode for whatever they want.  A mode can
do anything its author wants it to do.  I see that as a
good thing, not a bad thing.

What's the use case for such a restriction?  If it's to
allow for easier program analysis or something, it should
be enough to let people know (if appropriate) that if a
mode is not idempotent then it might be more difficult to
reason about its behavior.  (But reasoning about Lisp
behavior is anyway not something simple - Lisp is not
Haskell.)

The fact that most modes are likely idempotent should be
enough, I think.  Most mode writers don't go out of their
way to make a mode act differently if it is turned on more
than once.

Re: Should mode commands be idempotent?

[Stefan Monnier]

> What's the use case for such a restriction?

I'll return the question: when/why would a major-mode or a minor-mode
not want to be idempotent?  Can you cite at least one example?


        Stefan

RE: Should mode commands be idempotent?

[Drew Adams]

> > What's the use case for such a restriction?
> 
> I'll return the question: when/why would a major-mode or a minor-mode
> not want to be idempotent?  Can you cite at least one example?

I don't need to.  There should be some reasons given for making
a change, especially a change that attempt to restrict users,
whether by tooling or convention.

I've already accorded the assumption that most modes do
(already - with no need for such a requirement or convention)
have the requested property of idempotence.  Why reach further?

What's the real problem this request is trying to solve?

I repeat, "Why should it be a "requirement" or a convention?"

(No reason given, so far.)

Re: Should mode commands be idempotent?

[Stefan Monnier]

>> I'll return the question: when/why would a major-mode or a minor-mode
>> not want to be idempotent?  Can you cite at least one example?
> I don't need to.  There should be some reasons given for making
> a change, especially a change that attempt to restrict users,
> whether by tooling or convention.

Philip gave the reason in the first email: "it's generally expected that
mode commands (both major and minor) are reasonably idempotent".

Of course, we wouldn't decide on such a rule without weighing the pros
and cons.  But given that he mentioned one pro, we'd need at the very
least one cons before deciding it's a bad idea (no matter how weak the
pro).

Hence my question again (which is already implicitly contained in
Philip's original message):

    When/why would a major-mode or a minor-mode not want to be idempotent?
    Can you cite at least one example?

And of course, no restriction of the sort discussed here would limit
what the end user can do (we can't technically impose such
a restriction, we can only declare it's bad style).  In practice, such
a restriction would probably allow the user to do more things (because
he can now rely on the idempotency in his code): what you take on one
side, allows to give on the other.


        Stefan

RE: Should mode commands be idempotent?

[Drew Adams]

> > There should be some reasons given for making a change,
> > especially a change that attempt to restrict users,
> > whether by tooling or convention.
> 
> Philip gave the reason in the first email: "it's generally
> expected that mode commands (both major and minor) are
> reasonably idempotent".

If that's _already_ "generally expected", it's because,
as I said, most already _are_ "reasonably idempotent".

Since that is already generally expected, and is already
the case, I don't see a reason for adding a "requirement"
or a "convention" for that.  No reason for such a thing
has been given, so far.  The "reason" you cite just
restates the obvious and echoes the status quo, no?

A reason is what I'm asking for, not a statement that
this is already the case and therefore already generally 
expected, but a reason why we should make that already 
typical  practice a "requirement" or a "convention".

Having a convention that suggests that most modes should
be idempotent, when most already are, is like the father
of a first-born claiming to have taught his baby to say
"papa", whereas it's the other way 'round: the father's
word "papa" was invented by babies and taught to parents
(and heard by them slightly differently in different
languages).  It's (already) a de facto rule: just a
self-evident truth of experience.

Now if you instead were to propose that _all_ modes
_must_ then yes, it's likely that that's not currently
satisfied.  In that case, I'd ask why _all must_.

But if not - if all you're requesting is a rule that
_most_ _should_, _in general_, then my question is
why come up with such a rule?  What's it for?

Re: Should mode commands be idempotent?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

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.

As for minor modes, it has been pointed out (by Stefan?) that multiple
hooks could enable the same major mode, and the result should be the
same as if just one hook did so.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

RE: Should mode commands be idempotent?

[Drew Adams]

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

> As for minor modes, it has been pointed out (by Stefan?) that multiple
> hooks could enable the same major mode, and the result should be the
> same as if just one hook did so.

My question for this thread is this:

Is this proposal (add an explicit rule or convention stating
that mode functions should be idempotent) a solution looking
for a problem?

Has someone actually reported a problem that s?he ran into by
encountering an actual mode function that was not idempotent?

Re: Should mode commands be idempotent?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

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

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Should mode commands be idempotent?

[Clément Pit-Claudel]

On 2017-09-22 17:54, Drew Adams wrote:
> Has someone actually reported a problem that s?he ran into by
> encountering an actual mode function that was not idempotent?

I think I mentioned visual-line-mode; the fact that it's not idempotent is a concrete (though minor) problem for me.
I enable it in a hook, and a major mode that I use enables it too.  Due to the way visual-line-mode works, disabling it after this doesn't restore my original settings.

Clément.

RE: Should mode commands be idempotent?

[Drew Adams]

> > Has someone actually reported a problem that s?he ran into by
> > encountering an actual mode function that was not idempotent?
> 
> I think I mentioned visual-line-mode; the fact that it's not
> idempotent is a concrete (though minor) problem for me.  I enable
> it in a hook, and a major mode that I use enables it too.  Due to
> the way visual-line-mode works, disabling it after this doesn't
> restore my original settings.

`visual-line-mode' is distributed with Emacs.  It sounds like
what you report about it is a bug.

Or is `visual-line-mode' intentionally doing what it does, to
have some state be different for different times it is turned
on?  If not - if its non-idempotence is just an unintentional
behavior (a mistake), then it is just a bug that needs to be fixed.

That Emacs chooses to have its distributed modes be idempotent
is one thing.  That some 3rd-party code might also mistakenly
(unintentionally) prove to be non-idempotent is another, but
similar thing.  Such cases represent things to fix.

That is different from establishing a convention that
modes should never, intentionally or unintentionally,
be non-idempotent.

Re: Should mode commands be idempotent?

[Clément Pit-Claudel]

On 2017-09-24 19:26, Drew Adams wrote:
>>> Has someone actually reported a problem that s?he ran into by
>>> encountering an actual mode function that was not idempotent?
>>
>> I think I mentioned visual-line-mode; the fact that it's not
>> idempotent is a concrete (though minor) problem for me.  I enable
>> it in a hook, and a major mode that I use enables it too.  Due to
>> the way visual-line-mode works, disabling it after this doesn't
>> restore my original settings.
> …
> That Emacs chooses to have its distributed modes be idempotent
> is one thing.  That some 3rd-party code might also mistakenly
> (unintentionally) prove to be non-idempotent is another, but
> similar thing.  Such cases represent things to fix.
>
> That is different from establishing a convention that
> modes should never, intentionally or unintentionally,
> be non-idempotent.

Yes, of course; you asked whether non-idempotence had ever been an issue for anyone; I gave you one example :)

RE: Should mode commands be idempotent?

[Drew Adams]

> > That Emacs chooses to have its distributed modes be idempotent
> > is one thing.  That some 3rd-party code might also mistakenly
> > (unintentionally) prove to be non-idempotent is another, but
> > similar thing.  Such cases represent things to fix.
> >
> > That is different from establishing a convention that
> > modes should never, intentionally or unintentionally,
> > be non-idempotent.
> 
> Yes, of course; you asked whether non-idempotence had
> ever been an issue for anyone; I gave you one example :)

Yes.  Thanks.

FWIW, I did notice it the first time you mentioned it.
And I guessed that in the `visual-line-mode' case the
non-idempotence is not intentional or necessary.  And I
agreed with RMS that Emacs can (obviously) fix such bugs.  

My questions in this thread have to do with the
usefulness of adding a rule/convention that affects
_user_ code.  (I've seen some users blindly quote some
rules as catechism, without much nuance or understanding
what's involved.)

I'm in favor of good conventions that are explained well.
I'm not yet convinced that what is being talked about
here is a good user convention.

If we do add a (user-targeted) rule for this, it should
be made clear for users (1) what the motivation is and
(2) just what we intend by "idempotence".

Re: Should mode commands be idempotent?

[Stefan Monnier]

> I'm in favor of good conventions that are explained well.
> I'm not yet convinced that what is being talked about
> here is a good user convention.

It seems the general consensus in this discussion is that it might
indeed be a good convention. Since you disagree, maybe you could give us
some concrete arguments about why it might be desirable for
a minor/major mode to be non-idempotent.


        Stefan "who feels like he asked already but still hasn't heard
                any answer"

Re: Should mode commands be idempotent?

[John Wiegley]

>>>>> "SM" == Stefan Monnier <monnier@iro.umontreal.ca> writes:

SM> It seems the general consensus in this discussion is that it might indeed
SM> be a good convention. Since you disagree, maybe you could give us some
SM> concrete arguments about why it might be desirable for a minor/major mode
SM> to be non-idempotent.

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.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

RE: Should mode commands be idempotent?

[Drew Adams]

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

[John Wiegley]

>>>>> Drew Adams <drew.adams@oracle.com> writes:

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

Yes, idempotence: calling it N times is the exact same as calling it once.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

RE: Should mode commands be idempotent?

[Drew Adams]

> >> 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?
> 
> Yes, idempotence: calling it N times is the exact same as calling it once.

Good luck with such a guideline.  The state of an Emacs
session is _never_ exactly the same after each time you
turn on a mode - any mode, any session.  So many things
change...

If you don't want to specify what can and cannot change,
to be able to satisfy the guideline, then the guideline
is effectively useless.

This isn't Haskell.  (And even for Haskell the session
state changes.)

Re: Should mode commands be idempotent?

[John Wiegley]

>>>>> Drew Adams <drew.adams@oracle.com> writes:

> Good luck with such a guideline. The state of an Emacs session is _never_
> exactly the same after each time you turn on a mode - any mode, any session.
> So many things change...

I think we can reduce the scope of what we're saying:

The statement I made only applies if the command is called in immediate
succession. That is, the function is *itself* idempotent; it doesn't guarantee
that intervening effects are somehow negated.

That is, the following should be functionally equivalent:

    (foo-mode 1)
    (progn (foo-mode 1) (foo-mode 1))

I don't see what great difficulty this poses. If a mode author is doing thing
inside `foo-mode' like changing the system or the disk, that's exactly the
sort of thing our guideline seeks to prevent.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Should mode commands be idempotent?

[Philipp Stephani]

[-- Attachment #1.1: Type: text/plain, Size: 1032 bytes --]

John Wiegley <jwiegley@gmail.com> schrieb am Di., 26. Sep. 2017 um
20:55 Uhr:

> >>>>> Drew Adams <drew.adams@oracle.com> writes:
>
> > Good luck with such a guideline. The state of an Emacs session is _never_
> > exactly the same after each time you turn on a mode - any mode, any
> session.
> > So many things change...
>
> I think we can reduce the scope of what we're saying:
>
> The statement I made only applies if the command is called in immediate
> succession. That is, the function is *itself* idempotent; it doesn't
> guarantee
> that intervening effects are somehow negated.
>
> That is, the following should be functionally equivalent:
>
>     (foo-mode 1)
>     (progn (foo-mode 1) (foo-mode 1))
>
> I don't see what great difficulty this poses. If a mode author is doing
> thing
> inside `foo-mode' like changing the system or the disk, that's exactly the
> sort of thing our guideline seeks to prevent.
>

Given that all current and past maintainers seem to agree, how about the
following patch for the Lisp manual?

[-- Attachment #1.2: Type: text/html, Size: 1474 bytes --]

[-- Attachment #2: 0001-Document-that-mode-commands-should-be-idempotent.txt --]
[-- Type: text/plain, Size: 1363 bytes --]

From 466ee5853a07f90593149e4de07f92845e076170 Mon Sep 17 00:00:00 2001
From: Philipp Stephani <phst@google.com>
Date: Sun, 8 Oct 2017 17:25:31 +0200
Subject: [PATCH] Document that mode commands should be idempotent.

* doc/lispref/modes.texi (Major Mode Conventions, Minor Mode
Conventions): Document that the mode commands should be idempotent.
---
 doc/lispref/modes.texi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/doc/lispref/modes.texi b/doc/lispref/modes.texi
index f7013da943..f2fc742495 100644
--- a/doc/lispref/modes.texi
+++ b/doc/lispref/modes.texi
@@ -313,6 +313,10 @@ Major Mode Conventions
 Data}, for other possible forms).  The name of the mode appears
 in the mode line.
 
+@item
+Calling the major mode command twice in direct succession should not
+fail and should do the same thing as calling the command only once.
+
 @item
 @cindex functions in modes
 Since all global names are in the same name space, all the global
@@ -1412,6 +1416,10 @@ Minor Mode Conventions
 @noindent
 However, this is not very commonly done.
 
+  Enabling or disabling a minor mode twice in direct succession should
+not fail and should do the same thing as enabling or disabling it only
+once.
+
 @item
 Add an element to @code{minor-mode-alist} for each minor mode
 (@pxref{Definition of minor-mode-alist}), if you want to indicate the
-- 
2.14.2

Re: Should mode commands be idempotent?

[Stefan Monnier]

> +@item
> +Calling the major mode command twice in direct succession should not
> +fail and should do the same thing as calling the command only once.

I think I'd prefer it if the word "idempotent" was mentioned (not
*instead* of what you have, but additionally).

Other than that: LGTM.

        Stefan

Re: Should mode commands be idempotent?

[John Wiegley]

>>>>> "SM" == Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> +@item
>> +Calling the major mode command twice in direct succession should not
>> +fail and should do the same thing as calling the command only once.

SM> I think I'd prefer it if the word "idempotent" was mentioned (not
SM> *instead* of what you have, but additionally).

SM> Other than that: LGTM.

Same.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Should mode commands be idempotent?

[Philipp Stephani]

[-- Attachment #1: Type: text/plain, Size: 446 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> schrieb am So., 8. Okt. 2017 um
21:05 Uhr:

> > +@item
> > +Calling the major mode command twice in direct succession should not
> > +fail and should do the same thing as calling the command only once.
>
> I think I'd prefer it if the word "idempotent" was mentioned (not
> *instead* of what you have, but additionally).
>
> Other than that: LGTM.
>
>
Thanks, added and pushed to emacs-26 as 798f07f150.

[-- Attachment #2: Type: text/html, Size: 787 bytes --]

Re: Should mode commands be idempotent?

[Stefan Monnier]

> Thanks, added and pushed to emacs-26 as 798f07f150.

Thanks,


        Stefan

Re: Should mode commands be idempotent?

[Herring, Davis]

[Sorry this is so late: I only caught up on this upon seeing the manual patch.]

> The statement I made only applies if the command is called in immediate
> succession. That is, the function is *itself* idempotent; it doesn't guarantee
> that intervening effects are somehow negated.

There is a reasonable candidate condition, at least for minor modes, that is broader than this: if a minor mode has state, that state should not be reinitialized if the minor mode was already enabled before it is "enabled again".  For example, according to this principle compilation-minor-mode should not discard its markers if it is called again -- precisely because of other changes made between the calls.

For major modes, kill-all-local-variables tends to prevent this sort of idempotence.  This is not really a problem: since only one major mode can be active at a time, it makes sense to consider a second call to actually _replace_ the previous "instance" of the major mode.  There also isn't much reason to call major mode functions from places like hooks that might unexpectedly re-execute them.

Davis

RE: Should mode commands be idempotent?

[Drew Adams]

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

Re: Should mode commands be idempotent?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

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

Yes.

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

Sure it is.

We can't force anyone to follow our conventions.
We don't want to try to force anyone.

So we need not hesitate to state technical design conventions.
We can say that a non-idempotent mode is a bug.

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

That question sounds like a wild-goose chase.
I don't think we need to give it a precise answer.
"Enabling a mode should be idempotent" is enough to say.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Should mode commands be idempotent?

[John Wiegley]

>>>>> "PS" == Philipp Stephani <p.stephani2@gmail.com> writes:

PS> I think it's generally expected that mode commands (both major and minor)
PS> are reasonably idempotent, i.e. calling them twice should have the same
PS> effects as calling them once (unless using 'toggle, of course). However, I
PS> couldn't find this requirement in the manual, should it be added to the
PS> "Modes" section?

Actually, I'm used to turning off minor modes by just calling their mode
function a second time...

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Should mode commands be idempotent?

[Stefan Monnier]

> Actually, I'm used to turning off minor modes by just calling their mode
> function a second time...

Of course, the well known and documented toggling behavior of minor
modes is not what he was referring to.

For a minor mode he was thinking of calling it twice with a positive arg
or twice with a negative arg.  


        Stefan

Re: Should mode commands be idempotent?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I think it's generally expected that mode commands (both major and minor)
  > are reasonably idempotent, i.e. calling them twice should have the same
  > effects as calling them once (unless using 'toggle, of course). However, I
  > couldn't find this requirement in the manual, should it be added to the
  > "Modes" section?

This is the intended behavior, and has been all along.
It would be good to say so explicitly.

For major modes, as long as they work exclusively by setting
buffer-local variables and other per-buffer values (which they should),
kill-all-local-variables takes care of this automatically.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.