From: Alan Mackenzie <acm@muc.de>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Juri Linkov <juri@linkov.net>,
casouri@gmail.com, monnier@iro.umontreal.ca, larsi@gnus.org,
theo@thornhill.no, jostein@secure.kjonigsen.net,
emacs-devel@gnu.org
Subject: Re: Make all tree-sitter modes optional
Date: Tue, 14 Feb 2023 19:08:42 +0000 [thread overview]
Message-ID: <Y+vcOlOrpr6j85L8@ACM> (raw)
In-Reply-To: <83fsc92gbz.fsf@gnu.org>
Hello, Eli.
I missed this thread back in January, due to being away from Emacs
development for a time, and I think the current state of this feature is
so far away from ideal as to make some design and implementation
advisable.
On Tue, Jan 17, 2023 at 19:58:40 +0200, Eli Zaretskii wrote:
> > From: Juri Linkov <juri@linkov.net>
> > Cc: casouri@gmail.com, monnier@iro.umontreal.ca, larsi@gnus.org,
> > theo@thornhill.no, jostein@secure.kjonigsen.net, emacs-devel@gnu.org
> > Date: Tue, 17 Jan 2023 19:30:16 +0200
> > It fails for many scenarios:
> > 1. The user needs to use e.g. js-ts-mode. Your patch requires that
> > users first visit a js file in js-mode, then they need to type
> > M-x js-ts-mode RET
> > then for the rest of the session they can use js-ts-mode.
> > But for a new session they need to repeat the same again.
> Or customize auto-mode-alist.
> This is a consequence of the fact that js-ts-mode doesn't have a
> separate .el file. If you have better ideas for that, I'm all ears.
> > 2. For other ts modes adding something like (require 'c-ts-mode)
> > to the user's init file is not a clean way to enable such modes.
> Why not?
> > Also takes additional space even when users don't intend to use them
> > in the current session, thus negating the benefits of autoloading.
> Once again, if the above is somehow too annoying, they can customize
> auto-mode-alist manually. Or even use use-package (and have full
> benefit of autoloading). In any case, the fact that a mode is loaded
> and not used is not a problem large enough to reject this simple
> arrangement. Moreover, if someone puts the require into their init
> file, they probably want to use the mode quite a lot, so it will not
> remain ballast for too long.
> > 3. There is no simple way to disable a ts mode after loading
> > the corresponding ts file.
> Yes, there is: restart the session. IMO, adequate enough for
> something you want to try, and then find not to like.
No, it is not adequate. It is horrible. It forces the user to discard
all the state in his Emacs session, and restart, which is s..l..o..w..,
particularly if said user has a large desktop file. In my experiments
with c-ts-mode, I switched backwards and forwards several times between C
Mode and c-ts-mode. This now corrupts my Emacs session, in that C Mode
is no longer the default for C files. I got caught out this evening when
I opened a C file, and something failed to work on it because it opened
in c-ts-mode.
This seems to be undocumented in NEWS.
I think lots of users are going to hate having the new -ts- modes forced
upon them in this manner. Normally, when a new feature is introduced
into an Emacs version, it is fully optional, and defaults to disabled.
Why do the -ts- modes not conform to this well established practice?
There appears to be no way, apart from editing the Lisp source files, to
make C Mode the default for .c files when there are also c-ts-mode
buffers in the session. This is a Bad Thing.
> Bottom line: if you have better, simpler solutions, please tell.
How about commands c-make-ts-default-mode and c-make-ts-undefault-mode
(and analogous functions for the other ts-modes)? The first of these
would push the new entries onto auto-mode-alist and the second would
remove them again. Or we could have a customisable option,
c-default-c-mode which users could set when they are ready. Either of
these would allow the user to try out the new modes freely without being
coerced against their will to use the new -ts- modes.
> The ones you proposed until now are significantly more complex, and it
> is not reasonable to ask users to go to such lengths to try a new mode.
Any reasonable solution is going to be more complicated than the current
code. I don't think it reasonable silently to force users into setting the
new modes as defaults. They should be able to try out a new mode simply
by doing M-x c-ts-mode, or the like, then go back to their normal way of
working.
> But of course, if someone wants to do it in a more complex and more
> flexible way, they still can.
--
Alan Mackenzie (Nuremberg, Germany).
next prev parent reply other threads:[~2023-02-14 19:08 UTC|newest]
Thread overview: 119+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <84973.1672843723@hassadar.pretzelnet.org>
[not found] ` <83wn62xi3k.fsf@gnu.org>
[not found] ` <m1cz7u5brr.fsf@yahoo.es>
[not found] ` <83o7rexe2n.fsf@gnu.org>
[not found] ` <83h6x5xym7.fsf@gnu.org>
2023-01-15 14:01 ` Make all tree-sitter modes optional Eli Zaretskii
2023-01-15 23:39 ` Dmitry Gutov
2023-01-16 7:43 ` Theodor Thornhill
2023-01-16 16:30 ` Dmitry Gutov
2023-01-16 12:34 ` Eli Zaretskii
2023-01-16 13:06 ` Dmitry Gutov
2023-01-16 14:20 ` Eli Zaretskii
2023-01-16 14:50 ` Dmitry Gutov
2023-01-16 14:59 ` Eli Zaretskii
2023-01-17 12:59 ` Dmitry Gutov
2023-01-17 13:47 ` Eli Zaretskii
2023-01-17 14:32 ` Dmitry Gutov
2023-01-17 14:52 ` Eli Zaretskii
2023-01-17 15:22 ` Dmitry Gutov
2023-01-17 17:02 ` Eli Zaretskii
2023-01-17 17:10 ` Dmitry Gutov
2023-01-17 17:38 ` Eli Zaretskii
2023-01-17 17:59 ` Dmitry Gutov
2023-01-17 18:04 ` Eli Zaretskii
2023-01-17 18:21 ` Dmitry Gutov
2023-01-17 18:40 ` Eli Zaretskii
2023-01-17 18:49 ` Dmitry Gutov
2023-01-17 19:03 ` Eli Zaretskii
2023-01-17 19:21 ` Dmitry Gutov
2023-01-18 1:11 ` Yuan Fu
2023-01-18 1:23 ` Dmitry Gutov
2023-01-18 3:34 ` Eli Zaretskii
2023-01-18 3:52 ` Dmitry Gutov
2023-01-18 12:06 ` Eli Zaretskii
2023-01-18 14:00 ` Dmitry Gutov
2023-01-18 14:51 ` Eli Zaretskii
2023-01-18 12:36 ` Stefan Monnier
2023-01-17 17:34 ` treesit-forward-sexp (was: Make all tree-sitter modes optional) Juri Linkov
2023-01-17 17:40 ` Theodor Thornhill
2023-01-17 18:17 ` treesit-forward-sexp Juri Linkov
2023-01-17 17:50 ` treesit-forward-sexp (was: Make all tree-sitter modes optional) Dmitry Gutov
2023-01-17 17:59 ` Eli Zaretskii
2023-01-16 1:12 ` Make all tree-sitter modes optional Po Lu
2023-01-17 17:30 ` Juri Linkov
2023-01-17 17:58 ` Eli Zaretskii
2023-01-17 18:19 ` Juri Linkov
2023-01-17 18:41 ` Eli Zaretskii
2023-02-14 19:08 ` Alan Mackenzie [this message]
2023-02-14 19:29 ` Eli Zaretskii
2023-02-14 21:02 ` Alan Mackenzie
2023-02-15 15:35 ` Eli Zaretskii
2023-02-15 17:57 ` Alan Mackenzie
2023-02-15 18:33 ` Eli Zaretskii
2023-02-15 20:31 ` Alan Mackenzie
2023-02-16 5:41 ` tomas
2023-02-16 7:27 ` Eli Zaretskii
2023-02-16 22:05 ` Yuan Fu
[not found] ` <87v8k2g04m.fsf@dick>
2023-02-15 20:34 ` Eli Zaretskii
[not found] ` <87mt5eegkw.fsf@dick>
2023-02-16 7:53 ` Eli Zaretskii
2023-02-16 8:52 ` Po Lu
2023-02-15 21:40 ` Alan Mackenzie
2023-02-17 13:30 ` Alan Mackenzie
2023-02-17 13:37 ` Po Lu
2023-02-17 13:46 ` Stefan Monnier
2023-02-17 14:16 ` Po Lu
2023-02-17 14:40 ` Eli Zaretskii
2023-02-17 14:56 ` Dmitry Gutov
2023-02-17 15:04 ` Eli Zaretskii
[not found] ` <8735741fic.fsf@dick>
2023-02-17 15:41 ` Alan Mackenzie
2023-02-17 16:04 ` Make all tree-sitter modes optional Stefan Kangas
2023-02-17 17:42 ` Morgan Willcock
2023-02-17 15:15 ` Gregory Heytings
2023-02-17 13:54 ` Alan Mackenzie
[not found] ` <d4c1a7f6-b5bf-f4f3-8d79-1c6b1d07cf70@yandex.ru>
2023-02-17 14:22 ` Po Lu
2023-02-17 14:58 ` Eli Zaretskii
2023-02-17 15:18 ` Alan Mackenzie
2023-02-15 18:34 ` Stefan Monnier
2023-02-15 19:01 ` Dmitry Gutov
2023-02-15 19:26 ` Stefan Monnier
2023-02-15 19:47 ` Eli Zaretskii
2023-02-15 19:53 ` Stefan Monnier
2023-02-15 20:06 ` Eli Zaretskii
2023-02-15 21:04 ` Stefan Monnier
2023-02-16 7:42 ` Eli Zaretskii
2023-02-16 9:49 ` Basil L. Contovounesios
2023-02-16 11:48 ` Eli Zaretskii
2023-02-16 14:41 ` Stefan Monnier
2023-02-16 15:42 ` Eli Zaretskii
2023-02-16 16:45 ` Stefan Monnier
2023-02-16 17:05 ` Eli Zaretskii
2023-02-16 19:14 ` Dmitry Gutov
2023-02-16 20:07 ` Stefan Monnier
2023-02-16 5:45 ` tomas
2023-02-16 8:26 ` Eli Zaretskii
2023-02-16 10:30 ` Alan Mackenzie
2023-02-16 12:38 ` Po Lu
2023-02-16 12:53 ` Dmitry Gutov
2023-02-15 20:24 ` Dmitry Gutov
2023-02-16 7:05 ` Eli Zaretskii
2023-02-16 7:53 ` Theodor Thornhill
2023-02-16 8:34 ` Eli Zaretskii
2023-02-16 8:46 ` Theodor Thornhill
2023-02-16 11:58 ` Dmitry Gutov
2023-02-16 11:56 ` Dmitry Gutov
2023-02-16 14:48 ` Theodor Thornhill via Emacs development discussions.
2023-02-16 14:56 ` Dmitry Gutov
2023-02-16 15:15 ` Theodor Thornhill
2023-02-15 23:48 ` Lynn Winebarger
2023-02-16 2:56 ` Stefan Monnier
2023-02-15 19:07 ` Eli Zaretskii
2023-02-15 19:27 ` Stefan Monnier
2023-02-15 21:06 ` Basil L. Contovounesios
2023-02-16 7:44 ` Eli Zaretskii
2023-02-15 18:25 ` Juri Linkov
2023-01-19 16:53 Pedro Andres Aranda Gutierrez
2023-01-20 8:30 ` Eli Zaretskii
2023-01-20 16:31 ` Pedro Andres Aranda Gutierrez
2023-01-20 19:13 ` Eli Zaretskii
2023-01-21 11:30 ` Pedro Andres Aranda Gutierrez
2023-01-21 11:48 ` Eli Zaretskii
2023-01-22 6:23 ` Pedro Andres Aranda Gutierrez
2023-01-22 6:38 ` Eli Zaretskii
2023-01-22 10:46 ` Eli Zaretskii
-- strict thread matches above, loose matches on Subject: below --
2023-02-18 7:55 Pedro Andres Aranda Gutierrez
2023-03-11 12:45 ` Ongaro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y+vcOlOrpr6j85L8@ACM \
--to=acm@muc.de \
--cc=casouri@gmail.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=jostein@secure.kjonigsen.net \
--cc=juri@linkov.net \
--cc=larsi@gnus.org \
--cc=monnier@iro.umontreal.ca \
--cc=theo@thornhill.no \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).