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 :/