GNU bug report logs - #10773
define-derived-mode/define-minor-mode to declare hook variables

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 10773 in the body.
You can then email your comments to 10773 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: bug-gnu-emacs <at> gnu.org
Subject: set-variable can't change values of user options
Date: Thu, 09 Feb 2012 11:43:43 +0200

Package: emacs
Version: 24.0.93
Severity: wishlist

emacs -Q C-h C-t
M-x set-variable RET outline-mode-hook RET (hide-body) RET
M-x set-variable RET outline-minor-mode-hook RET [No match]

Why users are allowed to change the value of `outline-mode-hook',
but not `outline-minor-mode-hook'?

Message #8 received at 10773 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Juri Linkov <juri <at> jurta.org>
Cc: 10773 <at> debbugs.gnu.org
Subject: Re: bug#10773: set-variable can't change values of user options
Date: Thu, 09 Feb 2012 13:28:16 -0500

Juri Linkov wrote:

> Why users are allowed to change the value of `outline-mode-hook',
> but not `outline-minor-mode-hook'?

The former is defined with (defvar ... "*...").
The latter is not defined anywhere, but as define-derived-mode says
about hooks and has been covered several times:

  No problems result if this variable is not bound.
  `add-hook' automatically binds it.  (This is true for all hook variables.)

I would says it's not very useful to pass a hook to set-variable anyway,
since you need to type a lisp expression, and probably should use
an explicit add-hook statement.

Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Kevin Rodgers <kevin.d.rodgers <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#10773: set-variable can't change values of user options
Date: Fri, 10 Feb 2012 01:18:06 -0700

On 2/9/12 11:28 AM, Glenn Morris wrote:
> Juri Linkov wrote:
>
>> Why users are allowed to change the value of `outline-mode-hook',
>> but not `outline-minor-mode-hook'?
>
> The former is defined with (defvar ... "*...").
> The latter is not defined anywhere, but as define-derived-mode says
> about hooks and has been covered several times:
>
>    No problems result if this variable is not bound.
>    `add-hook' automatically binds it.  (This is true for all hook variables.)
>
> I would says it's not very useful to pass a hook to set-variable anyway,
> since you need to type a lisp expression, and probably should use
> an explicit add-hook statement.

Or allow add-hook (and remove-hook) to be called interactively, for convenience:

--- -	2012-02-10 01:14:16.000000000 -0700
+++ /tmp/subr.el	2012-02-10 01:13:17.000000000 -0700
@@ -1216,15 +1216,17 @@
 unless the optional argument APPEND is non-nil, in which case
 FUNCTION is added at the end.

-The optional fourth argument, LOCAL, if non-nil, says to modify
-the hook's buffer-local value rather than its default value.
-This makes the hook buffer-local if needed, and it makes t a member
-of the buffer-local value.  That acts as a flag to run the hook
-functions in the default value as well as in the local value.
+The optional fourth argument, LOCAL, if non-nil or an interactive
+prefix arg, says to modify the hook's buffer-local value rather
+than its default value.  This makes the hook buffer-local if
+needed, and it makes t a member of the buffer-local value.  That
+acts as a flag to run the hook functions in the default value as
+well as in the local value.

 HOOK should be a symbol, and FUNCTION may be any valid function.  If
 HOOK is void, it is first set to nil.  If HOOK's value is a single
 function, it is changed to a list of functions."
+  (interactive "SHook: \naFunction: \ni\nP")
   (or (boundp hook) (set hook nil))
   (or (default-boundp hook) (set-default hook nil))
   (if local (unless (local-variable-if-set-p hook)
@@ -1264,8 +1266,10 @@
 FUNCTION isn't the value of HOOK, or, if FUNCTION doesn't appear in the
 list of hooks to run in HOOK, then nothing is done.  See `add-hook'.

-The optional third argument, LOCAL, if non-nil, says to modify
-the hook's buffer-local value rather than its default value."
+The optional third argument, LOCAL, if non-nil (interactively,
+with prefix argument) says to modify the hook's buffer-local
+value rather than its default value."
+  (interactive "SHook: \naFunction: \nP")
   (or (boundp hook) (set hook nil))
   (or (default-boundp hook) (set-default hook nil))
   ;; Do nothing if LOCAL is t but this hook has no local binding.

-- 
Kevin Rodgers
Denver, Colorado, USA

Message #14 received at 10773 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 10773 <at> debbugs.gnu.org
Subject: Re: bug#10773: set-variable can't change values of user options
Date: Fri, 10 Feb 2012 12:18:56 +0200

>> Why users are allowed to change the value of `outline-mode-hook',
>> but not `outline-minor-mode-hook'?
>
> The former is defined with (defvar ... "*...").
> The latter is not defined anywhere, but as define-derived-mode says
> about hooks and has been covered several times:
>
>   No problems result if this variable is not bound.
>   `add-hook' automatically binds it.  (This is true for all hook variables.)
>
> I would says it's not very useful to pass a hook to set-variable anyway,
> since you need to type a lisp expression, and probably should use
> an explicit add-hook statement.

Currently William Stevenson is working on converting minor modes to use
`define-minor-mode', so more minor mode hooks will lose an ability to be
changed using `set-variable'.  I don't have an opinion whether this is
good or bad.  I just discovered the inconsistency between `outline-mode-hook'
and `outline-minor-mode-hook' when trying to set temporarily them
to the same value with `set-variable'.

What I still don't understand is why some hooks have "*" in the docstring.

Message #17 received at 10773 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Juri Linkov <juri <at> jurta.org>
Cc: 10773 <at> debbugs.gnu.org
Subject: Re: bug#10773: set-variable can't change values of user options
Date: Fri, 10 Feb 2012 12:31:32 -0500

Juri Linkov wrote:

> Currently William Stevenson is working on converting minor modes to use
> `define-minor-mode', so more minor mode hooks will lose an ability to be
> changed using `set-variable'.  I don't have an opinion whether this is
> good or bad. 

I think it is irrelevant / good.

> What I still don't understand is why some hooks have "*" in the docstring.

Perhaps it depends whether one interprets "*" as meaning "something a
user might want to set in .emacs", or "something a user might want to
set interactively" (this is what "Tips and Conventions" says).

Message #20 received at 10773 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Juri Linkov <juri <at> jurta.org>
Cc: 10773 <at> debbugs.gnu.org
Subject: Re: bug#10773: set-variable can't change values of user options
Date: Fri, 10 Feb 2012 13:01:50 -0500

Glenn Morris wrote:

>> Currently William Stevenson is working on converting minor modes to use
>> `define-minor-mode', so more minor mode hooks will lose an ability to be
>> changed using `set-variable'.  I don't have an opinion whether this is
>> good or bad. 
>
> I think it is irrelevant / good.

PS If it is thought to be bad, the right solution would seem to be to
make define-minor-mode declare the hook with an appropriate defvar,
which it easily could. But I think that has been previously rejected.

Message #23 received at 10773 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Juri Linkov <juri <at> jurta.org>, 10773 <at> debbugs.gnu.org
Subject: Re: bug#10773: set-variable can't change values of user options
Date: Sat, 11 Feb 2012 23:34:15 -0500

> But I think that has been previously rejected.

That was a long time ago.  We should do it for 24.2.


        Stefan

Message #26 received at 10773 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: Juri Linkov <juri <at> jurta.org>, 10773 <at> debbugs.gnu.org
Subject: Re: bug#10773: set-variable can't change values of user options
Date: Sun, 12 Feb 2012 15:16:07 -0500

Stefan Monnier wrote:

>> But I think that has been previously rejected.
>
> That was a long time ago.  We should do it for 24.2.

That's a surprise. What's changed?
This feature was taken out 2005-05-17.
Why does define-derived-mode deliberately go out of its way to NOT do
this? Will that be changed too?

Message #29 received at 10773 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Juri Linkov <juri <at> jurta.org>, 10773 <at> debbugs.gnu.org
Subject: Re: bug#10773: set-variable can't change values of user options
Date: Sun, 12 Feb 2012 21:58:38 -0500

>>> But I think that has been previously rejected.
>> That was a long time ago.  We should do it for 24.2.
> That's a surprise.  What's changed?

Resources.

> This feature was taken out 2005-05-17.
> Why does define-derived-mode deliberately go out of its way to NOT do
> this?  Will that be changed too?

Yes,


        Stefan

Message #34 received at 10773 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: 10773 <at> debbugs.gnu.org
Subject: Re: bug#10773: set-variable can't change values of user options
Date: Tue, 21 Feb 2012 02:40:54 +0200

In my opinion, the best way to eliminate the distinction
between user variables (with the leading '*' in the docstring)
and customizable variables in 24.2 is:

1. Make `user-variable-p' an alias for `custom-variable-p'.

2. Remove the `user-variable-p' condition from `set-variable'.

This will fix the reported case where `set-variable' can change
the value of `outline-mode-hook', but not `outline-minor-mode-hook';
and many other similar cases.

Message #37 received at 10773 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Juri Linkov'" <juri <at> jurta.org>, <10773 <at> debbugs.gnu.org>
Subject: RE: bug#10773: set-variable can't change values of user options
Date: Tue, 21 Feb 2012 07:26:57 -0800

> In my opinion, the best way to eliminate the distinction
> between user variables (with the leading '*' in the docstring)
> and customizable variables in 24.2 is:
> 
> 1. Make `user-variable-p' an alias for `custom-variable-p'.
> 
> 2. Remove the `user-variable-p' condition from `set-variable'.
> 
> This will fix the reported case where `set-variable' can change
> the value of `outline-mode-hook', but not `outline-minor-mode-hook';
> and many other similar cases.

And how will that help code that uses
(defvar foo "*A user variable.")?

Users have always been able to set such a user variable using `set-variable'.

Message #40 received at 10773 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 10773 <at> debbugs.gnu.org
Subject: Re: bug#10773: set-variable can't change values of user options
Date: Wed, 22 Feb 2012 02:16:10 +0200

>> In my opinion, the best way to eliminate the distinction
>> between user variables (with the leading '*' in the docstring)
>> and customizable variables in 24.2 is:
>>
>> 1. Make `user-variable-p' an alias for `custom-variable-p'.
>>
>> 2. Remove the `user-variable-p' condition from `set-variable'.
>>
>> This will fix the reported case where `set-variable' can change
>> the value of `outline-mode-hook', but not `outline-minor-mode-hook';
>> and many other similar cases.
>
> And how will that help code that uses
> (defvar foo "*A user variable.")?

IIUC, the plan is to deprecate this feature, to not maintain two parallel
systems of user customizable variables.

> Users have always been able to set such a user variable using `set-variable'.

With the proposed change above, users can continue to set variables
using `set-variable'.

Message #43 received at 10773 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: Juri Linkov <juri <at> jurta.org>, Glenn Morris <rgm <at> gnu.org>,
 10773 <at> debbugs.gnu.org
Subject: Re: bug#10773: set-variable can't change values of user options
Date: Sat, 19 Sep 2020 17:21:53 +0200

Stefan Monnier <monnier <at> IRO.UMontreal.CA> writes:

>> But I think that has been previously rejected.
>
> That was a long time ago.  We should do it for 24.2.

Reintroducing defvars for define-minor-mode hook variables was done the
following year:

commit 7f17cc40ef9120ba1b1715399432f26e8850505a
Author:     Stefan Monnier <monnier <at> iro.umontreal.ca>
AuthorDate: Mon May 27 12:12:52 2013 -0400

    Always defvar a mode's hook and provide a docstring.
    * lisp/emacs-lisp/easy-mmode.el (define-minor-mode):
    * lisp/emacs-lisp/derived.el (define-derived-mode): Always defvar the
    mode hook and provide a docstring.

There's still the question of using allowing these variables to be
customized, and that still doesn't work:

(customize-variable 'flyspell-mode-hook)
-> "NO CUSTOMIZATION DATA; not intended to be customized."

But...  why not?  So I've now added the patch below to Emacs 28.

diff --git a/lisp/emacs-lisp/easy-mmode.el b/lisp/emacs-lisp/easy-mmode.el
index e3eb9294ed..fdc1233540 100644
--- a/lisp/emacs-lisp/easy-mmode.el
+++ b/lisp/emacs-lisp/easy-mmode.el
@@ -335,6 +335,9 @@ define-minor-mode
 No problems result if this variable is not bound.
 `add-hook' automatically binds it.  (This is true for all hook variables.)"
                        modefun)))
+       ;; Allow using using `M-x customize-variable' on the hook.
+       (put ',hook 'custom-type 'hook)
+       (put ',hook 'standard-value (list nil))
 
        ;; Define the minor-mode keymap.
        ,(unless (symbolp keymap)	;nil is also a symbol.


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #50 received at 10773 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Juri Linkov <juri <at> jurta.org>, Glenn Morris <rgm <at> gnu.org>,
 10773 <at> debbugs.gnu.org
Subject: Re: bug#10773: set-variable can't change values of user options
Date: Sat, 19 Sep 2020 11:46:04 -0400

> There's still the question of using allowing these variables to be
> customized, and that still doesn't work:
>
> (customize-variable 'flyspell-mode-hook)
> -> "NO CUSTOMIZATION DATA; not intended to be customized."
>
> But...  why not?

I don't have a strong opinion either way.

>  So I've now added the patch below to Emacs 28.
>
> diff --git a/lisp/emacs-lisp/easy-mmode.el b/lisp/emacs-lisp/easy-mmode.el
> index e3eb9294ed..fdc1233540 100644
> --- a/lisp/emacs-lisp/easy-mmode.el
> +++ b/lisp/emacs-lisp/easy-mmode.el
> @@ -335,6 +335,9 @@ define-minor-mode
>  No problems result if this variable is not bound.
>  `add-hook' automatically binds it.  (This is true for all hook variables.)"
>                         modefun)))
> +       ;; Allow using using `M-x customize-variable' on the hook.
> +       (put ',hook 'custom-type 'hook)
> +       (put ',hook 'standard-value (list nil))
>  
>         ;; Define the minor-mode keymap.
>         ,(unless (symbolp keymap)	;nil is also a symbol.

Shouldn't we be using `defcustom` instead of hard-coding Custom's
"internal" properties?


        Stefan

Message #53 received at 10773 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Juri Linkov <juri <at> jurta.org>, Glenn Morris <rgm <at> gnu.org>,
 10773 <at> debbugs.gnu.org
Subject: Re: bug#10773: set-variable can't change values of user options
Date: Sat, 19 Sep 2020 17:49:02 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> Shouldn't we be using `defcustom` instead of hard-coding Custom's
> "internal" properties?

Yes.  But I was worried that defcustom would be too heavy-handed here.
And it seems unlikely that these properties would change much.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #56 received at 10773 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Juri Linkov <juri <at> jurta.org>, Glenn Morris <rgm <at> gnu.org>,
 10773 <at> debbugs.gnu.org
Subject: Re: bug#10773: set-variable can't change values of user options
Date: Sat, 19 Sep 2020 12:04:59 -0400

>> Shouldn't we be using `defcustom` instead of hard-coding Custom's
>> "internal" properties?
> Yes.  But I was worried that defcustom would be too heavy-handed here.

I think if you're worried about the "cost" of `defcustom`, then we may
as well stick to `defvar` (after all, it's not like it'll be very
easy/convenient for the user to use the Custom UI to add a function on
those hooks).


        Stefan

Message #59 received at 10773 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Juri Linkov <juri <at> jurta.org>, Glenn Morris <rgm <at> gnu.org>,
 10773 <at> debbugs.gnu.org
Subject: Re: bug#10773: set-variable can't change values of user options
Date: Sun, 20 Sep 2020 11:14:34 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>>> Shouldn't we be using `defcustom` instead of hard-coding Custom's
>>> "internal" properties?
>> Yes.  But I was worried that defcustom would be too heavy-handed here.
>
> I think if you're worried about the "cost" of `defcustom`, then we may
> as well stick to `defvar` 

I was mainly worried that defcustom had further other subtle effects
that I'm not aware of (:group? :version? the mandatory doc string?), but
looking at the code in custom-declare-variable, it looks pretty
straightforward...  (Famous last words.)

> (after all, it's not like it'll be very easy/convenient for the user
> to use the Custom UI to add a function on those hooks).

I think there's probably several bug reports about doing something about
that.  :-/

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.