GNU bug report logs -
#67207
[PATCH] Add elixir-ts-mode-hook to elixir-ts-mode
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 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.
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):
[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: 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):
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: 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):
> 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):
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: 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):
>>> 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.