bug#67207: [PATCH] Add elixir-ts-mode-hook to elixir-ts-mode

bug#67207: [PATCH] Add elixir-ts-mode-hook to elixir-ts-mode

[Wilhelm Kirschbaum]

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

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'

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-elixir-ts-mode-hook-to-elixir-ts-mode.patch --]
[-- Type: text/patch, Size: 1008 bytes --]

From 2ce080a17b7e89d63fb22826a91b931f987d8cf2 Mon Sep 17 00:00:00 2001
From: Wilhelm H Kirschbaum <wkirschbaum@gmail.com>
Date: Wed, 15 Nov 2023 20:13:02 +0200
Subject: [PATCH] Add elixir-ts-mode-hook to elixir-ts-mode

* lisp/progmodes/elixir-ts-mode.el
(elixir-ts-mode-hook): Make hook available to customize.
---
 lisp/progmodes/elixir-ts-mode.el | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/lisp/progmodes/elixir-ts-mode.el b/lisp/progmodes/elixir-ts-mode.el
index 05edb4159a1..ad7c599edb1 100644
--- a/lisp/progmodes/elixir-ts-mode.el
+++ b/lisp/progmodes/elixir-ts-mode.el
@@ -74,6 +74,13 @@ elixir-ts-indent-offset
   :safe 'integerp
   :group 'elixir-ts)
 
+(defcustom elixir-ts-mode-hook nil
+  "Hook run after entering `elixir-ts-mode'."
+  :type 'hook
+  :options '(eglot-ensure)
+  :group 'elixir-ts
+  :version "30.1")
+
 (defface elixir-ts-font-comment-doc-identifier-face
   '((t (:inherit font-lock-doc-face)))
   "Face used for @comment.doc tags in Elixir files.")
-- 
2.42.1

bug#67207: [PATCH] Add elixir-ts-mode-hook to elixir-ts-mode

[Eli Zaretskii]

> From: Wilhelm Kirschbaum <wkirschbaum@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?

bug#67207: [PATCH] Add elixir-ts-mode-hook to elixir-ts-mode

[Wilhelm Kirschbaum]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Wilhelm Kirschbaum <wkirschbaum@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.

bug#67207: [PATCH] Add elixir-ts-mode-hook to elixir-ts-mode

[Eli Zaretskii]

> From: Wilhelm Kirschbaum <wkirschbaum@gmail.com>
> Cc: 67207@debbugs.gnu.org
> Date: Wed, 15 Nov 2023 21:43:06 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Wilhelm Kirschbaum <wkirschbaum@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?

bug#67207: [PATCH] Add elixir-ts-mode-hook to elixir-ts-mode

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> 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

bug#67207: [PATCH] Add elixir-ts-mode-hook to elixir-ts-mode

[Wilhelm Kirschbaum]

Stefan Monnier <monnier@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

bug#67207: [PATCH] Add elixir-ts-mode-hook to elixir-ts-mode

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>>> 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#67207: [PATCH] Add elixir-ts-mode-hook to elixir-ts-mode

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Wilhelm Kirschbaum <wkirschbaum@gmail.com>,  67207@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.