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

Previous Next

Full log

View this message in rfc822 format

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: 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

Previous Next

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