turn-on-*-mode

turn-on-*-mode

[Sam Steingold]

What is the policy on the turn-on-*-mode and turn-off-*-mode functions?
Which modes get it and which don't?
Why is there turn-on-auto-fill but no turn-on-flyspell-mode?

-- 
Sam Steingold (http://www.podval.org/~sds) on Fedora Core release 5 (Bordeaux)
http://openvotingconsortium.org http://dhimmi.com http://thereligionofpeace.com
http://camera.org http://truepeace.org http://memri.org
The only intuitive interface is the nipple.  The rest has to be learned.

Re: turn-on-*-mode

[Richard Stallman]

    What is the policy on the turn-on-*-mode and turn-off-*-mode functions?
    Which modes get it and which don't?

We don't need to have a general policy.

Re: turn-on-*-mode

[Sam Steingold]

> * Richard Stallman <ezf@tah.bet> [2006-05-16 00:28:34 -0400]:
>
>     What is the policy on the turn-on-*-mode and turn-off-*-mode functions?
>     Which modes get it and which don't?
>
> We don't need to have a general policy.

OK, so if I want turn-on-flyspell-mode, do I just add it?

-- 
Sam Steingold (http://www.podval.org/~sds) on Fedora Core release 5 (Bordeaux)
http://pmw.org.il http://truepeace.org http://mideasttruth.com
http://iris.org.il http://dhimmi.com http://jihadwatch.org http://camera.org
Winners never quit; quitters never win; idiots neither win nor quit.

Re: turn-on-*-mode

[Lennart Borgman]

Sam Steingold wrote:
>> * Richard Stallman <ezf@tah.bet> [2006-05-16 00:28:34 -0400]:
>>
>>     What is the policy on the turn-on-*-mode and turn-off-*-mode functions?
>>     Which modes get it and which don't?
>>
>> We don't need to have a general policy.
>>     
>
> OK, so if I want turn-on-flyspell-mode, do I just add it?
>   
I think that even if Richard says that we do not need a general policy 
there are some advantages (and some drawbacks too of course) with having 
similar structures. The main advantage in my opinion is usability. 
Similar structures reduces unnecessary complexity. It is therefore more 
easy to remember for a user if things works in a similar way.

At least I want people using this software to be able to do things 
easily. That way I hope they are doing more of the things I like.

Re: turn-on-*-mode

[Kim F. Storm]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> Sam Steingold wrote:
>>> * Richard Stallman <ezf@tah.bet> [2006-05-16 00:28:34 -0400]:
>>>
>>>     What is the policy on the turn-on-*-mode and turn-off-*-mode functions?
>>>     Which modes get it and which don't?
>>>
>>> We don't need to have a general policy.

We could have a general policy to _discurage_ having such functions!

>>
>> OK, so if I want turn-on-flyspell-mode, do I just add it?

You are free to add whatever you like to your own .emacs file :-)


> I think that even if Richard says that we do not need a general policy
> there are some advantages (and some drawbacks too of course) with
> having similar structures. The main advantage in my opinion is
> usability. Similar structures reduces unnecessary complexity. It is
> therefore more easy to remember for a user if things works in a
> similar way.
>
> At least I want people using this software to be able to do things
> easily. That way I hope they are doing more of the things I like.

There are only three "turn-on-" and on "turn-off-" functions defined
in my Emacs with my normal .emacs.  Loading more packages may define
more of them, but I really don't want more of them, as this is still
an inconsistent interactive interface!  And for non-interactive use,
doing (*-mode 1) and (*-mode -1) is the preferred interface.

There are also a number of "toggle-" functions, which IMO is a much
better interface (just one function, with a simple common prefix).

We could even make a M-x toggle command which could toggle any mode
(it should provide a list of known modes as completion choices).
That would also be a good way to learn about new modes.

It might even toggle any boolean variable given a C-u prefix...

.. after the release!

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: turn-on-*-mode

[Sam Steingold]

> * Kim F. Storm <fgbez@phn.qx> [2006-05-16 16:52:51 +0200]:
>
> And for non-interactive use, doing (*-mode 1) and (*-mode -1) is the
> preferred interface.
> There are also a number of "toggle-" functions, which IMO is a much
> better interface (just one function, with a simple common prefix).

I think I should have been more clear about the background.
Yes, in a program, (*-mode *) is better.
Yes, interactively, M-x *-mode is better.

The only situation where the turn-on-*-mode functions are really needed
is hooks:
   (add-hook 'text-mode-hook 'turn-on-auto-fill)
is much better than
   (add-hook 'text-mode-hook (lambda () (auto-fill-mode 1)))

Maybe minor modes that are commonly enabled from hooks should have their
turn-on-* versions?

-- 
Sam Steingold (http://www.podval.org/~sds) on Fedora Core release 5 (Bordeaux)
http://jihadwatch.org http://iris.org.il http://palestinefacts.org
http://pmw.org.il http://memri.org http://dhimmi.com http://ffii.org
If you know that you know nothing, you know too much.

Re: turn-on-*-mode

[David Kastrup]

Sam Steingold <sds@podval.org> writes:

>> * Kim F. Storm <fgbez@phn.qx> [2006-05-16 16:52:51 +0200]:
>>
>> And for non-interactive use, doing (*-mode 1) and (*-mode -1) is the
>> preferred interface.
>> There are also a number of "toggle-" functions, which IMO is a much
>> better interface (just one function, with a simple common prefix).
>
> I think I should have been more clear about the background.
> Yes, in a program, (*-mode *) is better.
> Yes, interactively, M-x *-mode is better.
>
> The only situation where the turn-on-*-mode functions are really needed
> is hooks:
>    (add-hook 'text-mode-hook 'turn-on-auto-fill)
> is much better than
>    (add-hook 'text-mode-hook (lambda () (auto-fill-mode 1)))
>
> Maybe minor modes that are commonly enabled from hooks should have their
> turn-on-* versions?

Or maybe we should have something like

(defun add-hook-turn-on (hook mode)
  (add-hook hook `(lambda nil (,mode 1))))

So that one can write
(add-hook-turn-on 'text-mode-hook 'auto-fill-mode)

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

RE: turn-on-*-mode

[Drew Adams]

    Or maybe we should have something like
    
    (defun add-hook-turn-on (hook mode)
      (add-hook hook `(lambda nil (,mode 1))))
    
    So that one can write
    (add-hook-turn-on 'text-mode-hook 'auto-fill-mode)
    
I like that idea.

Re: turn-on-*-mode

[Lennart Borgman]

Drew Adams wrote:
>     Or maybe we should have something like
>     
>     (defun add-hook-turn-on (hook mode)
>       (add-hook hook `(lambda nil (,mode 1))))
>     
>     So that one can write
>     (add-hook-turn-on 'text-mode-hook 'auto-fill-mode)
>     
> I like that idea.
>   
I subscribe to that too.

Re: turn-on-*-mode

[Stuart D. Herring]

> Or maybe we should have something like
>
> (defun add-hook-turn-on (hook mode)
>   (add-hook hook `(lambda nil (,mode 1))))
>
> So that one can write
> (add-hook-turn-on 'text-mode-hook 'auto-fill-mode)

Or (somewhat tongue-in-cheek) have
(defun curry (func &rest args)
  `(lambda (&rest args2) (apply ',func (append ',args args2))))

So that one can write
(add-hook 'text-mode-hook (curry 'auto-fill-mode 1))
(add-hook 'makefile-mode-hook (curry 'auto-fill-mode -1))
(add-hook 'dired-after-readin-hook (curry 'message "T%ss i%sge%sng%sly!"
"hi" "s " "tti" " sil"))
(add-hook 'pre-command-hook
          (let* ((y (curry 'mapc (curry 'apply 'remove-hook)
                           '((pre-command-hook x) (post-command-hook y))))
                 (x (curry 'add-hook 'post-command-hook y)))
            (funcall #0=(lambda (c) (when (consp c)
                                      (funcall #0# (car c))
                                      (funcall #0# (cdr c))
                                      (if (memq (car c) '(x y))
                                          (setcar c (eval (car c)))))) x)
            x))

Too bad there's no IOLFC, eh?

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: turn-on-*-mode

[Johan Bockgård]

"Stuart D. Herring" <herring@lanl.gov> writes:

> Or (somewhat tongue-in-cheek) have
> (defun curry (func &rest args)
>   `(lambda (&rest args2) (apply ',func (append ',args args2))))
>
> So that one can write
> (add-hook 'text-mode-hook (curry 'auto-fill-mode 1))

The lexbind branch has this.

,----
| curry is a built-in function in `src/eval.c'.
| (curry fun &rest args)
| 
| Return fun curried with args.
| The result is a function-like object that will append any arguments it
| is called with to args, and call fun with the resulting list of
| arguments.
| 
| For instance:
|   (funcall (curry '+ 3 4 5) 2) is the same as (funcall '+ 3 4 5 2)
| and:
|   (mapcar (curry 'concat "The ") '("a" "b" "c"))
|   => ("The a" "The b" "The c")
`----

-- 
Johan Bockgård

Re: turn-on-*-mode

[Richard Stallman]

    Or maybe we should have something like

    (defun add-hook-turn-on (hook mode)
      (add-hook hook `(lambda nil (,mode 1))))

    So that one can write
    (add-hook-turn-on 'text-mode-hook 'auto-fill-mode)

This would be an improvement, if just using the minor mode
function is not acceptable (see the following message).

But even better would be a feature that makes it easy to use Custom to
specify minor modes to enable in any given major mode.

Re: turn-on-*-mode

[Richard Stallman]

    The only situation where the turn-on-*-mode functions are really needed
    is hooks:
       (add-hook 'text-mode-hook 'turn-on-auto-fill)
    is much better than
       (add-hook 'text-mode-hook (lambda () (auto-fill-mode 1)))

Right.  So my idea is, let's add such functions
for the modes people often want to enable in these hooks.

Re: turn-on-*-mode

[Reiner Steib]

On Wed, May 17 2006, Richard Stallman wrote:

>     The only situation where the turn-on-*-mode functions are really needed
>     is hooks:
>        (add-hook 'text-mode-hook 'turn-on-auto-fill)
>     is much better than
>        (add-hook 'text-mode-hook (lambda () (auto-fill-mode 1)))
>
> Right.  So my idea is, let's add such functions
> for the modes people often want to enable in these hooks.

I have added `turn-on-flyspell' and `turn-off-flyspell'.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: turn-on-*-mode

[Sam Steingold]

> * Reiner Steib <ervarefgrvo+tznar@vznc.pp> [2006-05-30 20:38:01 +0200]:
>
> On Wed, May 17 2006, Richard Stallman wrote:
>
>>     The only situation where the turn-on-*-mode functions are really needed
>>     is hooks:
>>        (add-hook 'text-mode-hook 'turn-on-auto-fill)
>>     is much better than
>>        (add-hook 'text-mode-hook (lambda () (auto-fill-mode 1)))
>>
>> Right.  So my idea is, let's add such functions
>> for the modes people often want to enable in these hooks.
>
> I have added `turn-on-flyspell' and `turn-off-flyspell'.

does this mean that the idea of making flyspell-mode et al turn on the
mode when called without arguments (like in hooks) is now abandoned?

http://article.gmane.org/gmane.emacs.devel:54613

-- 
Sam Steingold (http://www.podval.org/~sds) on Fedora Core release 5 (Bordeaux)
http://openvotingconsortium.org http://honestreporting.com http://dhimmi.com
http://truepeace.org http://jihadwatch.org http://memri.org
Isn't "Microsoft Works" an advertisement lie?

Re: turn-on-*-mode

[Reiner Steib]

On Tue, May 30 2006, Sam Steingold wrote:

>> * Reiner Steib <ervarefgrvo+tznar@vznc.pp> [2006-05-30 20:38:01 +0200]:
>> On Wed, May 17 2006, Richard Stallman wrote:
>>> Right.  So my idea is, let's add such functions
>>> for the modes people often want to enable in these hooks.
>>
>> I have added `turn-on-flyspell' and `turn-off-flyspell'.
>
> does this mean that the idea of making flyspell-mode et al turn on the
> mode when called without arguments (like in hooks) is now abandoned?
>
> http://article.gmane.org/gmane.emacs.devel:54613

It has been added to etc/TODO which means that is will happen after
the release.  My understanding is the Richard allows to add useful
turn-on-... commands now (before the release).  If I misunderstood, I
can revert my changes.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

RE: turn-on-*-mode

[Drew Adams]

    We could even make a M-x toggle command which could toggle any mode
    (it should provide a list of known modes as completion choices).
    That would also be a good way to learn about new modes.

    It might even toggle any boolean variable given a C-u prefix...
    after the release!

I suggested such a generic toggle with completion a while back - see thread
"add generic toggle, turn on,and turn off commands to Options menu"
(2006-03-04 and 2006-04-21-24). This also proposed adding such a generic
toggle to the Options menu, since that menu cannot accomodate an unlimited
number of specific toggle items.

Richard's decision was this:

    I don't like the idea of a generic toggle menu item.
    I don't think that is a helpful UI.  I don't have time to
    discuss it, though.

Of course, the idea of a generic toggle command need not be coupled with the
suggestion to add it to the Options menu. If the idea of such a command (but
not menu item) is still open (Richard?), then please see the previous thread
for some suggestions about treating quasi-binary options, that is, options
that are essentially binary but whose non-nil value need not be t.

Toggling a mode generically (your suggestion) is not necessarily the same as
toggling a user option generically, and mode-variable values are not always
nil and non-nil. But in many cases the treatment of the two could be the
same or similar. In any case, any discussion of one should perhaps also
consider the other.

FATHOC (For after the release, of course.)

Re: turn-on-*-mode

[Reiner Steib]

On Tue, May 16 2006, Kim F. Storm wrote:

> There are also a number of "toggle-" functions, which IMO is a much
> better interface (just one function, with a simple common prefix).

An advantage of turn-on-... (and turn-off-...) is that is simplifies
adding it to a hook:

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

BTW, AFAICS the `flyspell-mode' entry in the defcustom of
`text-mode-hook' toggles `flyspell-mode' instead of turning it on:

(defcustom text-mode-hook nil
  "Normal hook run when entering Text mode and many related modes."
  :type 'hook
  :options '(turn-on-auto-fill flyspell-mode)
  :group 'data)

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: turn-on-*-mode

[Miles Bader]

Reiner Steib <reinersteib+gmane@imap.cc> writes:
> An advantage of turn-on-... (and turn-off-...) is that is simplifies
> adding it to a hook:
>
>   (add-hook 'text-mode-hook 'turn-on-auto-fill)
>   (add-hook 'text-mode-hook (lambda () (flyspell-mode 1)))
>
> BTW, AFAICS the `flyspell-mode' entry in the defcustom of
> `text-mode-hook' toggles `flyspell-mode' instead of turning it on:

Stefan had a (what I thought was) clever suggestion to deal with this:
Make "...-mode" functions toggle only when used interactively (just as
they only print a message when used interactively), and otherwise have
them just enable the state unconditionally.

This is not a strictly compatible change, but in practice probably would
fix more problems than it would cause -- nobody in their right mind puts
a mode-function in a hook with the intention to toggle the state, but
people _do_ put mode functions in hooks _thinking_ that they
unconditionally enable the mode.

A possible variant of this idea that might be more compatible is to have
`run-hooks' bind a global variable to t when running a hook
(e.g. `running-hook'), and have mode function unconditionally enable the
mode when that variable is non-nil.

-Miles
-- 
It wasn't the Exxon Valdez captain's driving that caused the Alaskan oil spill.
It was yours.  [Greenpeace advertisement, New York Times, 25 February 1990]

Re: turn-on-*-mode

[Richard Stallman]

    Stefan had a (what I thought was) clever suggestion to deal with this:
    Make "...-mode" functions toggle only when used interactively (just as
    they only print a message when used interactively), and otherwise have
    them just enable the state unconditionally.

This is an interesting idea.

It would mean that there is no longer an argument you could use,
noninteractively, to toggle the mode.  But that is not a big loss,
practically speaking; that is not something people want to do in code
very often, and it is not very hard to toggle the mode by testing its
value.

Another drawback is simply that the interactive and noninteractive
behavior of these commands will be different.  I am not sure
how big a problem that is.

    A possible variant of this idea that might be more compatible is to have
    `run-hooks' bind a global variable to t when running a hook
    (e.g. `running-hook'), and have mode function unconditionally enable the
    mode when that variable is non-nil.

I like that less, because I think that special behavior for run-hooks
is a bigger anomaly than different behavior for interactive and
noninteractive calls.

Anyway, these changes should not be considered until after the release.

Re: turn-on-*-mode

[Stefan Monnier]

>     Stefan had a (what I thought was) clever suggestion to deal with this:
>     Make "...-mode" functions toggle only when used interactively (just as
>     they only print a message when used interactively), and otherwise have
>     them just enable the state unconditionally.

> This is an interesting idea.

> It would mean that there is no longer an argument you could use,
> noninteractively, to toggle the mode.

Actually there is: the symbol `toggle' does it.

> Another drawback is simply that the interactive and noninteractive
> behavior of these commands will be different.

Not really.  It just means that the argument passed to the minor mode
function in the absence of a prefix-arg won't be nil but will be `toggle'.
As a matter of fact, this is already the case.

The current code already emits a warning when the minor mode is called with
a nil argument and the minor mode is already enabled (i.e. when a nil
argument is used to toggle the mode off).


        Stefan

Re: turn-on-*-mode

[Richard Stallman]

    > It would mean that there is no longer an argument you could use,
    > noninteractively, to toggle the mode.

    Actually there is: the symbol `toggle' does it.

Ok.

    > Another drawback is simply that the interactive and noninteractive
    > behavior of these commands will be different.

    Not really.  It just means that the argument passed to the minor mode
    function in the absence of a prefix-arg won't be nil but will be `toggle'.
    As a matter of fact, this is already the case.

It sounds rather clean.  Would you please add it to etc/TODO?

Re: turn-on-*-mode

[Stefan Monnier]

> It sounds rather clean.  Would you please add it to etc/TODO?

Done,


        Stefan

Re: turn-on-*-mode

[Kevin Rodgers]

Kim F. Storm wrote:
> Lennart Borgman <lennart.borgman.073@student.lu.se> writes:
> 
>> Sam Steingold wrote:
>>>> * Richard Stallman <ezf@tah.bet> [2006-05-16 00:28:34 -0400]:
>>>>
>>>>     What is the policy on the turn-on-*-mode and turn-off-*-mode functions?
>>>>     Which modes get it and which don't?
>>>>
>>>> We don't need to have a general policy.
> 
> We could have a general policy to _discurage_ having such functions!

We do: neither define-minor-mode nor define-global-minor-mode define
turn-on-MODE-mode and turn-off-MODE-mode functions, or even provide
an option to do so.

>>> OK, so if I want turn-on-flyspell-mode, do I just add it?
> 
> You are free to add whatever you like to your own .emacs file :-)
> 
>> I think that even if Richard says that we do not need a general policy
>> there are some advantages (and some drawbacks too of course) with
>> having similar structures. The main advantage in my opinion is
>> usability. Similar structures reduces unnecessary complexity. It is
>> therefore more easy to remember for a user if things works in a
>> similar way.
>>
>> At least I want people using this software to be able to do things
>> easily. That way I hope they are doing more of the things I like.
> 
> There are only three "turn-on-" and on "turn-off-" functions defined
> in my Emacs with my normal .emacs.  Loading more packages may define
> more of them, but I really don't want more of them, as this is still
> an inconsistent interactive interface!  And for non-interactive use,
> doing (*-mode 1) and (*-mode -1) is the preferred interface.

The reason the turn-on-*-mode and turn-off-*-mode functions exist in the
first place is that the (*-mode 1) and (*-mode -1) calls have to be 
wrapped in a function definition (either a lambda form or a user-defined
function) in order to be added to a hook.

I think the turn-on-*-mode and turn-off-*-mode functions should be
provided for all local minor modes to provide a simpler idiom for that.
Global minor modes aren't used that way, are they?

> There are also a number of "toggle-" functions, which IMO is a much
> better interface (just one function, with a simple common prefix).
> 
> We could even make a M-x toggle command which could toggle any mode
> (it should provide a list of known modes as completion choices).
> That would also be a good way to learn about new modes.

There was a long discussion recently about how to programmatically
determine the minor-mode functions and/or variables, partly for the
purpose of presenting them to the user...

> It might even toggle any boolean variable given a C-u prefix...

I had such a command in my .emacs many years ago, but never used it
much.  `M-x toggle-truncate-lines' is a lot more convenient than
`M-x set-variable RET truncate-lines RET ... RET' though!

> .. after the release!

I hope I live to see it!

-- 
Kevin

Re: turn-on-*-mode

[Stefan Monnier]

> I had such a command in my .emacs many years ago, but never used it
> much.  `M-x toggle-truncate-lines' is a lot more convenient than
> `M-x set-variable RET truncate-lines RET ... RET' though!

I guess if the alternative is between

     M-x toggle  -  foo-mode RET
and
     M-x toggle RET foo-mode RET

it's really not that bad.  Although I do feel like the hyphen is much easier
to type ;-)


        Stefan