why do some programming modes have customize hooks and others do not?

why do some programming modes have customize hooks and others do not?

[Nic Ferrier]

Emacs-Lisp mode has a customizable hook variable but erlang-mode does
not.

Is there any reasoning to this discrepancy or is it just the personal
preference of the author of the mode?


Nic

Re: why do some programming modes have customize hooks and others do not?

[Bastien]

Hi Nic,

Nic Ferrier <nferrier@ferrier.me.uk> writes:

> Is there any reasoning to this discrepancy or is it just the personal
> preference of the author of the mode?

I suggest you send a patch or a bug report: you will get either the
reason why this is the way it is or a solution to your problem.

(Discrepancies are rarely the result of some reasoning.)

2 cts,

-- 
 Bastien

Re: why do some programming modes have customize hooks and others do not?

[Stefan Monnier]

> Emacs-Lisp mode has a customizable hook variable but erlang-mode does
> not.

define-derived-mode currently defines the hook with `defvar', so you'll
only get a customizable hook if the mode author explicitly added
a defcustom for it.

Maybe define-derived-mode should define the hook with defcustom.
I guess we'd need some motivation (other than "consistency") for that,
such as what would be the benefit to define the hook as a defcustom if
all the defcustom says is ":type hook".


        Stefan

Re: why do some programming modes have customize hooks and others do not?

[Nic Ferrier]

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

>> Emacs-Lisp mode has a customizable hook variable but erlang-mode does
>> not.
>
> define-derived-mode currently defines the hook with `defvar', so you'll
> only get a customizable hook if the mode author explicitly added
> a defcustom for it.

erlang-mode actually has a separate defvar for it.


Nic

Re: why do some programming modes have customize hooks and others do not?

[Rüdiger Sonderfeld]

On Saturday 18 October 2014 17:46:14 Stefan Monnier wrote:
> Maybe define-derived-mode should define the hook with defcustom.
> I guess we'd need some motivation (other than "consistency") for that,
> such as what would be the benefit to define the hook as a defcustom if
> all the defcustom says is ":type hook".

I've started working on a patch to add `:options' flags to mode hooks, such as 
`imenu-add-menubar-index' for modes supporting imenu or `eldoc-mode' for modes 
supporting eldoc.  In that process I started adding `defcustom' for hooks to 
modes which lacked one.  Since I'm currently busy with real work I stopped 
working on it.  If there is interest I could push the current state.  But this 
could of course also be a motivation to add such a feature to `define-derived-
mode'.  Although I'm not sure how to best represent it.  A `:hook-options' 
would probably miss the point.  Maybe a `:supported-minor-modes' option?

Regards,
Rüdiger

Re: why do some programming modes have customize hooks and others do not?

[Stefan Monnier]

> I've started working on a patch to add `:options' flags to mode hooks, such as 
> `imenu-add-menubar-index' for modes supporting imenu or `eldoc-mode' for modes 
> supporting eldoc.

FWIW, eldoc is now (in trunk) automatically enabled in any major mode
that supports it.

It should be fairly easy to add an imenu (sub)menu globally as well.


        Stefan

Re: why do some programming modes have customize hooks and others do not?

[Nic Ferrier]

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

>> I've started working on a patch to add `:options' flags to mode hooks, such as 
>> `imenu-add-menubar-index' for modes supporting imenu or `eldoc-mode' for modes 
>> supporting eldoc.
>
> FWIW, eldoc is now (in trunk) automatically enabled in any major mode
> that supports it.
>
> It should be fairly easy to add an imenu (sub)menu globally as well.

If I sent patches (once we're on git, how goes that?) for customize any
hooks that aren't already customizable, they would get accepted?


Nic

Re: why do some programming modes have customize hooks and others do not?

[Artur Malabarba]

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

> If I sent patches (once we're on git, how goes that?) for customize any
> hooks that aren't already customizable, they would get accepted?

I'd like to point out that saving a hook with the customize interface is
kind of asking for trouble.

Hooks are routinely added by arbitrary packages. If an unsuspecting user
customizes and saves a hook through the customize interface, any functions
that other packages have added to it will be saved as well.
If the user later removes one of these packages, he'll be confronted with
"undefined function" errors which no amount of restarting will solve.

The safe (and annoying) way to do this would be to define a second hook for
the user, and make that a defcustom.

Malabarba

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

Re: why do some programming modes have customize hooks and others do not?

[Nic Ferrier]

bruce.connor.am@gmail.com writes:

>> If I sent patches (once we're on git, how goes that?) for customize any
>> hooks that aren't already customizable, they would get accepted?
>
> I'd like to point out that saving a hook with the customize interface is
> kind of asking for trouble.
>
> Hooks are routinely added by arbitrary packages. If an unsuspecting user
> customizes and saves a hook through the customize interface, any functions
> that other packages have added to it will be saved as well.
> If the user later removes one of these packages, he'll be confronted with
> "undefined function" errors which no amount of restarting will solve.
>
> The safe (and annoying) way to do this would be to define a second hook for
> the user, and make that a defcustom.

I agree this is a problem, though I've always seen it as a problem with
the packages that do that.

As a package author I try and always make a way to specify whether what
I'm adding to hooks should be done or not:

   my-mode-add-myself-to-such-and-such-a-hook y/n

for example.

Separating hooks into 2 sections might work but introduces other
problems.

If I use a hooked function to autoload my package, then using the
non-customize hook won't work. The user ends up having to require my
package in their .emacs.


I think the route of all this is that there are a significant number of
authors who don't care about customize and don't try and use it.

Is that fair?



Nic

Re: why do some programming modes have customize hooks and others do not?

[Artur Malabarba]

> If I use a hooked function to autoload my package, then using the
> non-customize hook won't work. The user ends up having to require my
> package in their .emacs.

I don't understand. Why would the hooked function not load your package?

> I think the route of all this is that there are a significant number of
> authors who don't care about customize and don't try and use it.

Yes.
Another possible solution to this conundrum would be for the customize
interface itself to provide special treatment on hook variables.

Customize can keep track of which functions were added through
the interface.
Whenever the hook is customized, only those items are displayed
on the interface (or maybe the other items are displayed but not editable).
When the user makes some change and performs a save, Customize then
saves only the user-added functions. The other ones are left in the
hook, but they are not saved to “custom-file”.

This would have almost no effect on the user and the authors, but
would prevent packages from leaving garbage behind. It might be a
little cumbersome to code, but I don't forsee any fundamental problems
with it.

Anyone?

Re: why do some programming modes have customize hooks and others do not?

[Stefan Monnier]

> If I sent patches (once we're on git, how goes that?)

Same as for Bzr, yes.

> for customize any hooks that aren't already customizable, they would
> get accepted?

Depends on the specifics.  E.g. just changing the defcustom with a ":type
'hook" would probably not be accepted because the downside (pointed out
by Artur) isn't made up by significant extra convenience.
But if the change includes some genuinely useful extra info (e.g. good
suggestions for functions to add to this particular hook), it might make
it acceptable.


        Stefan

Re: why do some programming modes have customize hooks and others do not?

[Stefan Monnier]

> Another possible solution to this conundrum would be for the customize
> interface itself to provide special treatment on hook variables.

Indeed.


        Stefan

Re: why do some programming modes have customize hooks and others do not?

[Nic Ferrier]

Artur Malabarba <bruce.connor.am@gmail.com> writes:

>> If I use a hooked function to autoload my package, then using the
>> non-customize hook won't work. The user ends up having to require my
>> package in their .emacs.
>
> I don't understand. Why would the hooked function not load your
> package?

The scenario I'm thinking of is where a package adds itself to a hook to
get itself auto-initialized.

If the hook isn't saved (eg: by customize) then of course the contents
will be lost.

That's all I meant. Customizable hooks are good for packages to hook
into (with enough user consent) because they are persistent.


> Yes.
> Another possible solution to this conundrum would be for the customize
> interface itself to provide special treatment on hook variables.
>
> Customize can keep track of which functions were added through
> the interface.

That is a *really* good idea.


> Whenever the hook is customized, only those items are displayed
> on the interface (or maybe the other items are displayed but not editable).
> When the user makes some change and performs a save, Customize then
> saves only the user-added functions. The other ones are left in the
> hook, but they are not saved to “custom-file”.
>
> This would have almost no effect on the user and the authors, but
> would prevent packages from leaving garbage behind. It might be a
> little cumbersome to code, but I don't forsee any fundamental problems
> with it.
>
> Anyone?

It's a brilliant solution I think.

I'd be happy to implement it (when we have git).


Nic

Re: why do some programming modes have customize hooks and others do not?

[Nic Ferrier]

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

>> If I sent patches (once we're on git, how goes that?)
>
> Same as for Bzr, yes.

Not the same as for bzr, no. I don't have bzr and don't intend to
install it.

I'm happy to contribute on git though.


> Depends on the specifics.  E.g. just changing the defcustom with a ":type
> 'hook" would probably not be accepted because the downside (pointed out
> by Artur) isn't made up by significant extra convenience.
> But if the change includes some genuinely useful extra info (e.g. good
> suggestions for functions to add to this particular hook), it might make
> it acceptable.

I think Artur had a good idea which I'd be happy to implement. Then it
would be worth switching hook variables to customize.


Nic

Re: why do some programming modes have customize hooks and others do not?

[Stefan Monnier]

>>> If I sent patches (once we're on git, how goes that?)
>> Same as for Bzr, yes.
> Not the same as for bzr, no.  I don't have bzr and don't intend to
> install it.

You don't need to have Bzr to send patches, even though we currently
use Bzr.  Same will hold for Git.

You do need Bzr if you want to commit patches yourself, OTOH.

> I'm happy to contribute on git though.

And once we've switched to Git (any day now), you'll need Git to commit
(which shouldn't be a problem for you, apparently).

> I think Artur had a good idea which I'd be happy to implement.
> Then it would be worth switching hook variables to customize.

It's worth a try, yes.


        Stefan