turning on minor modes from hooks

turning on minor modes from hooks

[Dan Nicolaescu]

Now that local variables can be used to reliably turn on minor modes,
maybe it would be a good idea to turn on minor modes from hooks.

For example now one has to do this to turn on auto-file-mode in
text-mode:

(add-hook 'text-mode-hook   'turn-on-auto-fill)

instead of just:

(add-hook 'text-mode-hook   'auto-fill-mode)

This avoids defining extra functions just for the purpose of being able
to call them from hooks.

Not sure how feasible is to have a clean implementation of such a feature...

WDYT?

Re: turning on minor modes from hooks

[Miles Bader]

Dan Nicolaescu <dann@ics.uci.edu> writes:
> (add-hook 'text-mode-hook   'auto-fill-mode)
>
> This avoids defining extra functions just for the purpose of being able
> to call them from hooks.
>
> Not sure how feasible is to have a clean implementation of such a feature...

Stephen has long advocated that non-interactive invocation of mode
commands should always turn on the mode instead of toggling.

I agree with that:  I think the vast majority of uses in code do not use
the toggling anyway, and while there probably are a few uses which would
be broken by such a change, I think there would be far _more_
currently-incorrect uses that would be _fixed_ by such a change (where
someone uses (add-hook 'foo-hook 'ack-mode) not realizing that it really
toggles instead of turning on).

-miles

-- 
Acquaintance, n. A person whom we know well enough to borrow from, but not
well enough to lend to.

RE: turning on minor modes from hooks

[Drew Adams]

> > (add-hook 'text-mode-hook   'auto-fill-mode)
> >
> > This avoids defining extra functions just for the purpose 
> > of being able to call them from hooks.

There's never been a need to define an "extra function" for use on a hook.

(add-hook 'text-mode-hook (lambda () (auto-fill-mode 1)))

> > Not sure how feasible is to have a clean implementation of 
> > such a feature...
> 
> Stephen has long advocated that non-interactive invocation of mode
> commands should always turn on the mode instead of toggling.

So interactively a nil arg will toggle, but in Lisp a nil arg will turn it on?
And just why is that a great idea?

> I agree with that:  I think the vast majority of uses in code 
> do not use the toggling anyway, and while there probably are
> a few uses which would be broken by such a change, I think
> there would be far _more_ currently-incorrect uses

In libraries or in user init files? The latter, maybe, at least until they
discover that it doesn't do what they thought. That doesn't take long...

> that would be _fixed_ by such a change (where someone uses
> (add-hook 'foo-hook 'ack-mode) not realizing that it really
> toggles instead of turning on).

"Not realizing" is the key phrase. This is not about being unable to understand,
I think. It's about ordinary ignorance. It's about things not being the way some
newbies expect, without reading the doc.

There are lots of such Emacs-Lisp gotchas that new users learn about soon
enough. What's so special about this one? This one they learn about as soon as
they try it the first time.

Or, barring simple trial and error, they can actually read the doc (quelle
horreur !) to find out that a nil arg toggles. It's the same thing for learning
about quoting or list structure or hooks or anything else: things might not be
what you expect if you don't read a little. Emacs puts the info at your
fingertips with doc strings and such - really not a biggee.

It's not as if this is something complex and difficult for users to understand -
some people just don't bother to check a doc string or Info.

You seem to contrast ignorance about the arg, on the one hand, with the entire
body of existing Lisp code that uses mode functions, on the other. Granted, most
mode-function calls do not toggle the mode, but I don't think toggling is that
rare.

Not to mention code that might specifically test the arg, treating nil
differently from a positive integer - oops, guess what, starting with Emacs 23.2
they act the same...

I'd rather not expect library authors to have to adjust their existing code that
toggles the mode, to make it call (foo-mode (not foo-mode)) instead of
(foo-mode). I'd rather they not need to adjust code that examines the arg and
acts accordingly, changing the logic for Emacs post-23.1.

I'd rather that new users just read the doc and learn this FAQ, like so many
other FAQs. Not a biggee, and neither is using `lambda' in a hook. This is a
YAGNI feature, at best, and a bug-producer and code complexifier, at worst.

No, I don't feel very strongly about this, but I do not think it's a great idea.

Re: turning on minor modes from hooks

[Miles Bader]

"Drew Adams" <drew.adams@oracle.com> writes:
>> Stephen has long advocated that non-interactive invocation of mode
>> commands should always turn on the mode instead of toggling.
>
> So interactively a nil arg will toggle, but in Lisp a nil arg will turn it on?
> And just why is that a great idea?

Er, because it works the command work "as expected" in all contexts,
instead of in just one.

>> I agree with that:  I think the vast majority of uses in code 
>> do not use the toggling anyway, and while there probably are
>> a few uses which would be broken by such a change, I think
>> there would be far _more_ currently-incorrect uses
>
> In libraries or in user init files?

Mostly in user init files -- uses in libraries mostly won't be affected,
as they tend to explicitly specify the argument, and explicitly
set or reset the mode, not toggle it.

> The latter, maybe, at least until they
> discover that it doesn't do what they thought. That doesn't take long...

That's exactly the problem -- it _does_ take long for a user to
discover, because the default state for most modes is "off", and so
toggling _usually_ does the right thing.  Inadvertent use of the
toggling behavior tends to result in obscure and hard to locate bugs
(because it "usually" works right, and only fails in the rare case where
the mode happens to be already turned on for some reason).

>> that would be _fixed_ by such a change (where someone uses
>> (add-hook 'foo-hook 'ack-mode) not realizing that it really
>> toggles instead of turning on).
>
> "Not realizing" is the key phrase. This is not about being unable to understand,
> I think. It's about ordinary ignorance. It's about things not being the way some
> newbies expect, without reading the doc.

Yes.  Of course the doc should be good, but it's pretty clear that in
practice, it's not enough -- people don't always read the doc, or don't
read it carefully enough, or aren't experienced enough to understand all
the ramifications of what they're reading (the latter can be addressed
to some extent by careful wording, but it's almost impossible to do
reach all users).

Thus it's really really useful if we can have _both_ good docs _and_
commands that work intuitively.  Belt and braces, etc, etc.

> This is a YAGNI feature, at best, and a bug-producer and code
> complexifier, at worst.

I think you're wrong.  It will cause some bugs, but it will fix far more.

-Miles

-- 
I'm beginning to think that life is just one long Yoko Ono album; no rhyme
or reason, just a lot of incoherent shrieks and then it's over.  --Ian Wolff

RE: turning on minor modes from hooks

[Drew Adams]

> >> Stephen has long advocated that non-interactive invocation of mode
> >> commands should always turn on the mode instead of toggling.
> >
> > So interactively a nil arg will toggle, but in Lisp a nil 
> > arg will turn it on? And just why is that a great idea?
> 
> Er, because it works the command work "as expected" in all contexts,
> instead of in just one.

Er, and why would one "expect" a nil arg to work differently between Lisp and
interactive use?

And why would one "expect" the _particular_ behavior difference you define?

> >> I agree with that:  I think the vast majority of uses in code 
> >> do not use the toggling anyway, and while there probably are
> >> a few uses which would be broken by such a change, I think
> >> there would be far _more_ currently-incorrect uses
> >
> > In libraries or in user init files?
> 
> Mostly in user init files -- uses in libraries mostly won't 
> be affected, as they tend to explicitly specify the argument,
> and explicitly set or reset the mode, not toggle it.

I already agreed that most Lisp uses are not for toggling. I don't agree that
toggling in Lisp is so rare that it should be ignored. Especially if no real
advantage to doing so is given.

> > The latter, maybe, at least until they
> > discover that it doesn't do what they thought. That doesn't 
> take long...
> 
> That's exactly the problem -- it _does_ take long for a user to
> discover, 

We disagree. I think people discover this _very_ quickly. I've seen it happen on
help-gnu-emacs and Emacs Wiki. It's certainly easier to discover than how
`quote' works or `setq' or `setcdr'. It's easier to discover than how `add-hook'
works (to come closer to home).

I haven't noticed any great misunderstanding in this regard. The only
misunderstanding I've seen is early and ephemeral, and only from people who
never even looked at the doc string.

> because the default state for most modes is "off", and so
> toggling _usually_ does the right thing.

We disagree. Toggling can only turn it on every other time the mode is entered
(in a given buffer or, if a global minor mode, everywhere).

> Inadvertent use of the toggling behavior tends to result in
> obscure and hard to locate bugs

Bugs? I thought you were talking about a user's use of add-hook in an init file.

By "bug", I think of faulty Elisp code somewhere - is it the inappropriate
add-hook that you have in mind by "bug"?

What kind of "obscure and hard to locate bugs" are created by such inappropriate
use in a user's init file?

> (because it "usually" works right, 

Disagree.

> and only fails in the rare case where the mode happens to
> be already turned on for some reason).

Why is that a rare case? Do you never toggle a mode? If so, each time it is
turned on, the hook applies and toggles the other mode. I don't see that such
toggling "usually works right", if the expectation is that the mode be turned
on.

> >> that would be _fixed_ by such a change (where someone uses
> >> (add-hook 'foo-hook 'ack-mode) not realizing that it really
> >> toggles instead of turning on).
> >
> > "Not realizing" is the key phrase. This is not about being 
> > unable to understand, I think. It's about ordinary ignorance.
> > It's about things not being the way some newbies expect,
> > without reading the doc.
> 
> Yes.  Of course the doc should be good, but it's pretty clear that in
> practice, it's not enough -- people don't always read the 
> doc, or don't read it carefully enough, or aren't experienced
> enough to understand all the ramifications of what they're reading
> (the latter can be addressed to some extent by careful wording,
> but it's almost impossible to do reach all users).

The doc can always be improved, of course.

The question is about the users you have in mind here. In what I've seen, the
users who have misunderstood about the nil arg have nearly always been those who
didn't read the doc - at all. Once it was pointed out to them, things were
clear. The behavior and the doc were clear - they just needed to be pointed out.

As you said, you will never get all users to always consult the doc first. But
that's the case for nearly every facet of Emacs Lisp. "Misunderstanding" that
comes *only* from not consulting the doc does not imply that the design is wrong
or needs changing. Far from it. If we took that approach, we'd throw out 99.99%
of the design.

Think of the number (increasing, it seems) of people who send the simplest
questions to help-gnu-emacs, rather than taking a quick look at a doc string. We
should not change the design of Emacs just because they didn't bother to check
the doc first. That would be ridiculous.

Hey, some people are lazy. More frequently, out of ignorance they think it's
easier to ask help-gnu-emacs than to ask Emacs. They don't yet know about `C-h
f' and Info and apropos...

That doesn't mean that the design is wrong, just because they didn't guess right
the first time.

Misunderstanding that comes from poorly written doc is a different story - the
fix for that is to improve the doc.

Misunderstanding that comes from a poor design is yet another story. In such
cases, users cannot understand the behavior because it is inherently
contradictory or nonsensical. That is not the case here.

The UI (including the code interface) is consistent, clear, simple, and
understandable. Users who misunderstand the nil arg do so, in my experience,
*only* because they never looked at the doc (e.g. doc string). I've never seen
anyone not understand once the behavior was pointed out. This is not hard to
get.

> Thus it's really really useful if we can have _both_ good docs _and_
> commands that work intuitively.  Belt and braces, etc, etc.

I don't see that the current design is unintuitive. Of course, one can argue
anything one likes in terms of "intuitive" and "natural" - we won't get far with
such labels.

Please show what is contradictory (for example) in the current design. Show what
is difficult to understand (once one has read the description). Show anything
inherently difficult about the current behavior. Saying it is "unintuitive" just
isn't persuasive.

> > This is a YAGNI feature, at best, and a bug-producer and code
> > complexifier, at worst.
> 
> I think you're wrong.  It will cause some bugs, but it will 
> fix far more.

Describe one kind of software bug that it will fix. I pointed out a couple kinds
of problems it will introduce. Surely you can come up with one kind that it will
fix.

I'm talking bugs here, not an inappropriate add-hook in an init file. (If you
really must count that, OK, count it as one bug.)

But what kinds of programming bugs will this fix? You already admitted that the
add-hook gotcha is not a problem in code (libraries) - it's just a newbie
init-file thing. So how is this going to help with Elisp programming - what
kinds of bugs ("far more") will it fix?

Re: turning on minor modes from hooks

[Miles Bader]

"Drew Adams" <drew.adams@oracle.com> writes:
>> > So interactively a nil arg will toggle, but in Lisp a nil 
>> > arg will turn it on? And just why is that a great idea?
>> 
>> Er, because it works the command work "as expected" in all contexts,
>> instead of in just one.
>
> Er, and why would one "expect" a nil arg to work differently between Lisp and
> interactive use?

One "wouldn't", because it _won't_ work differently.  The meaning of `nil'
will change (from "toggle" to "set").  The argument passed to the function
when invoked interactively is determined by the (interactive ...) form, so
the (interactive ...) form will be changed to pass `toggle' instead of
nil.

> And why would one "expect" the _particular_ behavior difference you define?

The toggling nature when invoked M-x is very natural, and ingrained;
we've also observed that people expect the "set" behavior when using a
mode as a hook.

> I already agreed that most Lisp uses are not for toggling. I don't agree that
> toggling in Lisp is so rare that it should be ignored. Especially if no real
> advantage to doing so is given.

It won't be "ignored", it will still be possible via use of `toggle' as an argument.

The advantage is more natural use (and thus fewer usage bugs).

[The rest of your email then completely ignores everything I've said
before and proceeds to ask questions already answered.  Maybe you truly
didn't understand the answers and are honestly asking, but I'm sorry, I
don't have the stomach for these long drawn out and insanely verbose
arguing-for-the-sake-of-arguing threads.]

-Miles

-- 
"Though they may have different meanings, the cries of 'Yeeeee-haw!' and
 'Allahu akbar!' are, in spirit, not actually all that different."

Re: turning on minor modes from hooks

[Stefan Monnier]

>> Stephen has long advocated that non-interactive invocation of mode
   ^^^^^^^
Was that meant to be me?

>> commands should always turn on the mode instead of toggling.

> So interactively a nil arg will toggle, but in Lisp a nil arg will
> turn it on?  And just why is that a great idea?

No:  currently, minor modes defined with `define-minor-mode' will never
receive nil when invoked interactively.  They'll either get a prefix
arg, or the symbol `toggle'.

The patch below would change define-minor-mode as suggested.


        Stefan


--- lisp/emacs-lisp/easy-mmode.el	2009-01-05 10:18:22 +0000
+++ lisp/emacs-lisp/easy-mmode.el	2009-07-24 02:11:35 +0000
@@ -225,12 +225,7 @@
                  (cond
                   ((eq arg 'toggle) (not ,mode))
                   (arg (> (prefix-numeric-value arg) 0))
-                  (t
-                   (if (null ,mode) t
-                     (message
-                      "Toggling %s off; better pass an explicit argument."
-                      ',mode)
-                     nil))))
+		(t)))
            ,@body
            ;; The on/off hooks are here for backward compatibility only.
            (run-hooks ',hook (if ,mode ',hook-on ',hook-off))

Re: turning on minor modes from hooks

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> Stephen has long advocated that non-interactive invocation of mode
>    ^^^^^^^
> Was that meant to be me?

Er, yeah; sorry...

-miles

-- 
Quack, n. A murderer without a license.

Re: turning on minor modes from hooks

[Richard Stallman]

    Stephen has long advocated that non-interactive invocation of mode
    commands should always turn on the mode instead of toggling.

A call with no arguments, as in (auto-save-mode), naturally ought to
toggle the mode or turn it on.  But (auto-save-mode nil) has the
natural meaning of turning the mode off.

Perhaps we could make minor mode functions take &rest arguments so
they can distinguish those two cases.  However, that could be a
painful change,

Re: turning on minor modes from hooks

[Stefan Monnier]

> A call with no arguments, as in (auto-save-mode), naturally ought to
> toggle the mode or turn it on.

Cae to explain why?


        Stefan

Re: turning on minor modes from hooks

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> A call with no arguments, as in (auto-save-mode), naturally ought to
>> toggle the mode or turn it on.
>
> Care to explain why?

Note that he said "or turn it on"; I think the point was to distinguish
those possibilities from "unconditionally turn it off".

Probably most programmers would agree that having (foo-mode)
unconditionally disable foo-mode would be pretty weird...!  Having
(foo-mode nil) turn it on or toggle is actually a bit weird too, though
a bit less so...

Using &rest  is generally not a good idea because it conses,
but... since mode functions are generally not called in inner loops,
maybe it would be OK for this case...?

[It would be nice if elisp supported cheap non-nil defaults for
&optional args...]

-miles

-- 
Accordion, n. An instrument in harmony with the sentiments of an assassin.

Re: turning on minor modes from hooks

[Stefan Monnier]

>>> A call with no arguments, as in (auto-save-mode), naturally ought to
>>> toggle the mode or turn it on.
>> Care to explain why?
> Note that he said "or turn it on"; I think the point was to distinguish
> those possibilities from "unconditionally turn it off".

Toggling is just wrong for it.  I understand why it's like this right
now, but from an Lisp point of view, it's just not the right choice, and
there's no need here to distinguish a nil arg from the absence of an arg.


        Stefan

Re: turning on minor modes from hooks

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>>> A call with no arguments, as in (auto-save-mode), naturally ought to
>>>> toggle the mode or turn it on.
>>> Care to explain why?
>>
>> Note that he said "or turn it on"; I think the point was to distinguish
>> those possibilities from "unconditionally turn it off".
>
> Toggling is just wrong for it.

Right, but the second possibility, "turn it on" (and I interpreted that
to mean "unconditionally turn it on"), is right, and he _did_ say
"or"...

> I understand why it's like this right now, but from an Lisp point of
> view, it's just not the right choice, and there's no need here to
> distinguish a nil arg from the absence of an arg.

I agree that toggling is wrong for the elisp interface, but I disagree
with the rest of that -- as a programmer, (foo) and (foo nil) _do_ look
like entirely different things; the fact that they're conflated in elisp
seems like an implementation detail, not a design choice; it's generally
harmless, but on occasion can result in annoyingly counter-intuitive
interfaces.

In the case of mode functions, ideally I _could_ use (foo-mode) _or_
(foo-mode t) to turn on foo mode, and (foo-mode nil) to turn it off.
Those usages seem like the natural ones to me, given no implementation
constraints.

-Miles

-- 
Vote, v. The instrument and symbol of a freeman's power to make a fool of
himself and a wreck of his country.

Re: turning on minor modes from hooks

[Richard Stallman]

    > A call with no arguments, as in (auto-save-mode), naturally ought to
    > toggle the mode or turn it on.

    Cae to explain why?

When you call a major mode function, it selects that mode.
So when users call a minor mode function, they will expect it
to select that mode too.

Re: turning on minor modes from hooks

[Stefan Monnier]

>> A call with no arguments, as in (auto-save-mode), naturally ought to
>> toggle the mode or turn it on.

>     Care to explain why?

> When you call a major mode function, it selects that mode.
> So when users call a minor mode function, they will expect it
> to select that mode too.

So you argue for "turn it on" rather than "toggle".  I fully agree.


        Stefan

Re: turning on minor modes from hooks

[Richard Stallman]

    > When you call a major mode function, it selects that mode.
    > So when users call a minor mode function, they will expect it
    > to select that mode too.

    So you argue for "turn it on" rather than "toggle".

Not necessarily.  This case should't be considered in isolation but
rather as part of an overall design for minor modes.

One design that occurs to me is (foo-mode) turns it on, (foo-mode t)
turns it on, (foo-mode nil) turns it off, and the way you toggle is
(foo-mode (not foo-mode)).

Another is (foo-mode) toggles, (foo-mode t) turns it on, (foo-mode
nil) turns it off.

I am not sure which of those is better.  I don't think we should
reject either out of hand.

The current convention for interactive calls seems clear and natural
so I think it should be preserved, whatever we do with calls from Lisp.

Re: turning on minor modes from hooks

[Stefan Monnier]

> One design that occurs to me is (foo-mode) turns it on, (foo-mode t)
> turns it on, (foo-mode nil) turns it off, and the way you toggle is
> (foo-mode (not foo-mode)).

(foo-mode 'toggle) toggles it.
I'm not necessarily opposed to (foo-mode (not foo-mode)) but it can't be
used in the interactive spec, because we want the command-history to say
"toogle" rather than "turn on" or "turn off", in case the user wants to
repeat it.

> Another is (foo-mode) toggles,

That's what we have and it sucks, because it means that

  (add-hook 'bar-hook foo-mode)

doesn't do what the user usually intends to do.  Same thing with
-*- mode: foo -*-.  That's why (foo-mode) needs to unconditionally turn
the mode on.

> The current convention for interactive calls seems clear and natural
> so I think it should be preserved, whatever we do with calls from Lisp.

Agreed.


        Stefan

Re: turning on minor modes from hooks

[Richard Stallman]

    (foo-mode 'toggle) toggles it.

That seems fine to me.

    I'm not necessarily opposed to (foo-mode (not foo-mode)) but it can't be
    used in the interactive spec, because we want the command-history to say
    "toogle" rather than "turn on" or "turn off", in case the user wants to
    repeat it.

That is a good point.

Re: turning on minor modes from hooks

[Geoff Gole]

>> What about some kind of enable-minor-mode function?

> If you mean a generic function that can enable specific minor modes,
> that will just cause proliferation of definitions like

> (defun turn-on-auto-fill () (enable-minor-mode 'auto-fill-mode))
> (defun turn-off-auto-fill () (disable-minor-mode 'auto-fill-mode))

Not necessarily. It could return a function suitable for inclusion in a hook:

 (defun turn-on (minor-mode-symbol)
     `(lambda () (,minor-mode-symbol t)))

  (add-hook 'foo-mode-hook (turn-on 'some-minor-mode))

Or maybe

  (defun turn-on (&rest minor-mode-symbols)
    `(lambda () ,@(mapcar (lambda (sym) (list sym t))
                          minor-mode-symbols)))

  (add-hook 'foo-mode-hook (turn-on 'foo-minor-mode 'bar-minor-mode))

Excuse the fake lexical scoping hack. turn-on is probably also not the
right name, as (turn-on 'mode) not turning on any mode might be
confusing.

Re: turning on minor modes from hooks

[Daniel Colascione]

On Sunday 30 August 2009, Richard Stallman wrote:
>     Stephen has long advocated that non-interactive invocation of mode
>     commands should always turn on the mode instead of toggling.

Isn't magically changing behavior between the interactive and non-interactive cases a Bad Thing?

> A call with no arguments, as in (auto-save-mode), naturally ought to
> toggle the mode or turn it on.  But (auto-save-mode nil) has the
> natural meaning of turning the mode off.
> 
> Perhaps we could make minor mode functions take &rest arguments so
> they can distinguish those two cases.  However, that could be a
> painful change,

What about some kind of enable-minor-mode function?

Re: turning on minor modes from hooks

[Tassilo Horn]

Daniel Colascione <danc@merrillprint.com> writes:

Hi!

>> A call with no arguments, as in (auto-save-mode), naturally ought to
>> toggle the mode or turn it on.  But (auto-save-mode nil) has the
>> natural meaning of turning the mode off.
>> 
>> Perhaps we could make minor mode functions take &rest arguments so
>> they can distinguish those two cases.  However, that could be a
>> painful change,
>
> What about some kind of enable-minor-mode function?

That's what a some minor modes already do, for example
`turn-on-eldoc-mode', `turn-on-follow-mode', or
`turn-on-gnus-dired-mode'.  For some of them there's also a turn-off
command.

Maybe that's a good convention.  If so, then probably things like
`define-minor-mode' should generate those functions automatically.

BTW, for me the toggling has never been a problem.  When I customize
some mode by putting stuff in its hook, I always define some
`th-foo-mode-init' function where I put stuff into.  And then it makes
no difference in wether I write (some-minor-mode) or (some-minor-mode 1)
there.  But I agree that it's a problem when customizing with the
`customize' interface...

Bye,
Tassilo

Re: turning on minor modes from hooks

[Richard Stallman]

    > What about some kind of enable-minor-mode function?

    That's what a some minor modes already do, for example
    `turn-on-eldoc-mode', `turn-on-follow-mode', or
    `turn-on-gnus-dired-mode'.  For some of them there's also a turn-off
    command.

    Maybe that's a good convention.  If so, then probably things like
    `define-minor-mode' should generate those functions automatically.

This approach defines functions in a profligate way.
It would be much better to do something simpler and more elegant.

Re: turning on minor modes from hooks

[Stefan Monnier]

>> Stephen has long advocated that non-interactive invocation of mode
>> commands should always turn on the mode instead of toggling.
> Isn't magically changing behavior between the interactive and
> non-interactive cases a Bad Thing?

There's no magic involved: if you call (call-interactively 'foo-mode)
it will toggle just fine, but you have no reason to presume that this is
equivalent to (foo-mode).  And indeed it's not.


        Stefan

Re: turning on minor modes from hooks

[Stephen J. Turnbull]

Daniel Colascione writes:

 > Isn't magically changing behavior between the interactive and
 > non-interactive cases a Bad Thing?

No.  XEmacs inverts the (boolean) prefix arg in some cases where
experience shows that interactive usage by far favored the prefixed
version.  This was hotly opposed in theory, in practice everybody
loved it immediately.  It turned out that C-e and M-: (end-of-line) RET
are not aliases in our minds (YMMV), but rather synonyms, and we don't
have trouble making the subtle semantic distinction.  (NB, the command
in question isn't `end-of-line', but I don't remember which it is and
a quick grep shows that "invert" isn't the word used in the docstring.)

 > What about some kind of enable-minor-mode function?

If you mean a generic function that can enable specific minor modes,
that will just cause proliferation of definitions like

(defun turn-on-auto-fill () (enable-minor-mode 'auto-fill-mode))
(defun turn-off-auto-fill () (disable-minor-mode 'auto-fill-mode))