GNU bug report logs - #67207
[PATCH] Add elixir-ts-mode-hook to elixir-ts-mode

Previous Next

Package: emacs;

Reported by: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>

Date: Wed, 15 Nov 2023 18:36:02 UTC

Severity: normal

Tags: patch

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

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

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#67207; Package emacs. (Wed, 15 Nov 2023 18:36:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Wed, 15 Nov 2023 18:36:02 GMT) Full text and rfc822 format available.

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

From: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] Add elixir-ts-mode-hook to elixir-ts-mode
Date: Wed, 15 Nov 2023 20:32:42 +0200
[Message part 1 (text/plain, inline)]
Tags: patch


This change was requested by a user and seems to be useful.

I am also trying the `submit-emacs-patch` command, so hope I am 
doing it
right. 

In GNU Emacs 30.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version
3.24.38, cairo version 1.18.0) of 2023-11-14 built on _
Repository revision: 3074f4cfc2efc5a1d75186ad44790a21cecda3d3
Repository branch: master
System Description: Arch Linux

Configured using:
'configure --with-sound=yes --with-json --with-pgtk
--with-native-compilation=aot --with-xwidgets --with-imagemagick
--with-tree-sitter'
[0001-Add-elixir-ts-mode-hook-to-elixir-ts-mode.patch (text/patch, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#67207; Package emacs. (Wed, 15 Nov 2023 19:39:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>
Cc: 67207 <at> debbugs.gnu.org
Subject: Re: bug#67207: [PATCH] Add elixir-ts-mode-hook to elixir-ts-mode
Date: Wed, 15 Nov 2023 21:38:11 +0200
> From: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>
> Date: Wed, 15 Nov 2023 20:32:42 +0200
> 
> This change was requested by a user and seems to be useful.

Sorry, I don't understand: what was the request of that user?
elixir-ts-mode is defined using define-derived-mode, which
automatically creates a mode hook, so why do you need to define it
explicitly?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#67207; Package emacs. (Wed, 15 Nov 2023 19:55:01 GMT) Full text and rfc822 format available.

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

From: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 67207 <at> debbugs.gnu.org
Subject: Re: bug#67207: [PATCH] Add elixir-ts-mode-hook to elixir-ts-mode
Date: Wed, 15 Nov 2023 21:43:06 +0200
Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>
>> Date: Wed, 15 Nov 2023 20:32:42 +0200
>> 
>> This change was requested by a user and seems to be useful.
>
> Sorry, I don't understand: what was the request of that user?
> elixir-ts-mode is defined using define-derived-mode, which
> automatically creates a mode hook, so why do you need to define 
> it
> explicitly?

I had exactly the same question.  The user wants to manage the 
elixir-ts-mode hooks from the customize-group menu and not using 
elisp.  This seems to be the way to make it show up on the 
customize-group menu for elixir-ts-mode.  There are some other 
modes doing the same if you search for `defcustom .*-mode-hook` 
under the progmode folder.

If this is undesirable or if there is another way to make it show 
up on the customize menu, it will be good to know.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#67207; Package emacs. (Wed, 15 Nov 2023 19:59:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 67207 <at> debbugs.gnu.org
Subject: Re: bug#67207: [PATCH] Add elixir-ts-mode-hook to elixir-ts-mode
Date: Wed, 15 Nov 2023 21:58:03 +0200
> From: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>
> Cc: 67207 <at> debbugs.gnu.org
> Date: Wed, 15 Nov 2023 21:43:06 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>
> >> Date: Wed, 15 Nov 2023 20:32:42 +0200
> >> 
> >> This change was requested by a user and seems to be useful.
> >
> > Sorry, I don't understand: what was the request of that user?
> > elixir-ts-mode is defined using define-derived-mode, which
> > automatically creates a mode hook, so why do you need to define 
> > it
> > explicitly?
> 
> I had exactly the same question.  The user wants to manage the 
> elixir-ts-mode hooks from the customize-group menu and not using 
> elisp.  This seems to be the way to make it show up on the 
> customize-group menu for elixir-ts-mode.  There are some other 
> modes doing the same if you search for `defcustom .*-mode-hook` 
> under the progmode folder.
> 
> If this is undesirable or if there is another way to make it show 
> up on the customize menu, it will be good to know.

Adding Stefan to the discussion.

Stefan, does this mean define-derived-mode has some deficiency?
Many/most modes defined using it don't have an explicit hook
definition, so should we now define a mode hook for all of them?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#67207; Package emacs. (Wed, 15 Nov 2023 22:57:01 GMT) Full text and rfc822 format available.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>, 67207 <at> debbugs.gnu.org
Subject: Re: bug#67207: [PATCH] Add elixir-ts-mode-hook to elixir-ts-mode
Date: Wed, 15 Nov 2023 17:53:52 -0500
> Stefan, does this mean define-derived-mode has some deficiency?
> Many/most modes defined using it don't have an explicit hook
> definition, so should we now define a mode hook for all of them?

Usually we don't have good ideas of `:options` to provide for hook
variables, so it's not very useful to expose them to Custom.

Also, it's not rare for hook variables to be modified by other packages,
which again votes in favor of not exposing them to Custom.

But some mode maintainers do like to expose them to Custom for their
users' convenience.  Usually I look at it as a hint that there's
something missing elsewhere (for the patch at hand, maybe some kind of
`global-eglot-mode` would be a better answer in the longer term).

We could try and extend `define-derived-mode` to allow it to expose the
hook to Custom, with `:options` and whatnot, but it doesn't seem worth
the trouble since the maintainer can use a separate explicit `defcustom`
instead, as the OP's patch does.


        Stefan





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#67207; Package emacs. (Sat, 18 Nov 2023 08:56:02 GMT) Full text and rfc822 format available.

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

From: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 67207 <at> debbugs.gnu.org
Subject: Re: bug#67207: [PATCH] Add elixir-ts-mode-hook to elixir-ts-mode
Date: Sat, 18 Nov 2023 10:32:22 +0200
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> Stefan, does this mean define-derived-mode has some deficiency?
>> Many/most modes defined using it don't have an explicit hook
>> definition, so should we now define a mode hook for all of 
>> them?
>
> Usually we don't have good ideas of `:options` to provide for 
> hook
> variables, so it's not very useful to expose them to Custom.
>

After I had a look how it works, it seems pretty convenient for 
users
relying on customize menus and not knowing which hooks might be 
useful.
There are some modes using this feature, but its not consistently 
used.

For the elixir-ts-mode users, it appears there are very few people 
not
running either eglot or lsp-mode, so having eglot-ensure hook on 
the
menu makes sense to me.

Discovering features and minor modes in Emacs is not as intuitive 
to
newcomers and some direction of which options are available might 
help a
bit.

> Also, it's not rare for hook variables to be modified by other 
> packages,
> which again votes in favor of not exposing them to Custom.
>
> But some mode maintainers do like to expose them to Custom for 
> their
> users' convenience.  Usually I look at it as a hint that there's
> something missing elsewhere (for the patch at hand, maybe some 
> kind of
> `global-eglot-mode` would be a better answer in the longer 
> term).

Yes, agreed.  If a user can toggle somewhere that they want to run 
a
language server for this mode, or better a project then the need 
to have
the hook for eglot-ensure won't be needed anymore.

>
> We could try and extend `define-derived-mode` to allow it to 
> expose the
> hook to Custom, with `:options` and whatnot, but it doesn't seem 
> worth
> the trouble since the maintainer can use a separate explicit 
> `defcustom`
> instead, as the OP's patch does.

Won't it make sense to define a hook to custom anyways, so that 
users
get used to the idea of using the customize menus to add hooks? 
Instead
of only a handful of modes having it available?  Then it can be
additionally configured by the maintainer.

Only after using Emacs for 5+ years now I am only now discovering 
the
convenience of the customize menu, probably getting too lazy to 
update
init.el.

Wilhelm




Reply sent to Eli Zaretskii <eliz <at> gnu.org>:
You have taken responsibility. (Sat, 18 Nov 2023 10:05:01 GMT) Full text and rfc822 format available.

Notification sent to Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>:
bug acknowledged by developer. (Sat, 18 Nov 2023 10:05:02 GMT) Full text and rfc822 format available.

Message #25 received at 67207-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: wkirschbaum <at> gmail.com, 67207-done <at> debbugs.gnu.org
Subject: Re: bug#67207: [PATCH] Add elixir-ts-mode-hook to elixir-ts-mode
Date: Sat, 18 Nov 2023 12:03:55 +0200
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>,  67207 <at> debbugs.gnu.org
> Date: Wed, 15 Nov 2023 17:53:52 -0500
> 
> > Stefan, does this mean define-derived-mode has some deficiency?
> > Many/most modes defined using it don't have an explicit hook
> > definition, so should we now define a mode hook for all of them?
> 
> Usually we don't have good ideas of `:options` to provide for hook
> variables, so it's not very useful to expose them to Custom.
> 
> Also, it's not rare for hook variables to be modified by other packages,
> which again votes in favor of not exposing them to Custom.
> 
> But some mode maintainers do like to expose them to Custom for their
> users' convenience.  Usually I look at it as a hint that there's
> something missing elsewhere (for the patch at hand, maybe some kind of
> `global-eglot-mode` would be a better answer in the longer term).
> 
> We could try and extend `define-derived-mode` to allow it to expose the
> hook to Custom, with `:options` and whatnot, but it doesn't seem worth
> the trouble since the maintainer can use a separate explicit `defcustom`
> instead, as the OP's patch does.

Thanks, I installed the change and added a comment regarding the
reasons.

Closing.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#67207; Package emacs. (Sun, 19 Nov 2023 03:40:02 GMT) Full text and rfc822 format available.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 67207 <at> debbugs.gnu.org
Subject: Re: bug#67207: [PATCH] Add elixir-ts-mode-hook to elixir-ts-mode
Date: Sat, 18 Nov 2023 22:39:30 -0500
>>> Stefan, does this mean define-derived-mode has some deficiency?
>>> Many/most modes defined using it don't have an explicit hook
>>> definition, so should we now define a mode hook for all of them?
>> Usually we don't have good ideas of `:options` to provide for hook
>> variables, so it's not very useful to expose them to Custom.
> After I had a look how it works, it seems pretty convenient for users
> relying on customize menus and not knowing which hooks might be useful.
> There are some modes using this feature, but its not consistently used.

Yes but it's unreliable: as soon as some code uses `add-hook` on this
hook variable, Custom gets all confused because it doesn't know
why/where the variable has a different value from the one it expected.

> Won't it make sense to define a hook to custom anyways, so that users
> get used to the idea of using the customize menus to add hooks?

As long as Custom breaks down when someone uses `add-hook`, I don't feel
comfortable exposing unsuspecting users to the brittleness of hooks in
Custom :-(

Custom's main audience is specifically those users who don't (want to) know
about such tricky interactions.

> Only after using Emacs for 5+ years now I am only now discovering the
> convenience of the customize menu, probably getting too lazy to update
> init.el.

:-)


        Stefan





bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sun, 17 Dec 2023 12:24:06 GMT) Full text and rfc822 format available.

This bug report was last modified 1 year and 145 days ago.

Previous Next


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