[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Make all tree-sitter modes optional
From: |
Dmitry Gutov |
Subject: |
Re: Make all tree-sitter modes optional |
Date: |
Mon, 16 Jan 2023 15:06:15 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 |
On 16/01/2023 14:34, Eli Zaretskii wrote:
Date: Mon, 16 Jan 2023 01:39:18 +0200
Cc: emacs-devel@gnu.org
From: Dmitry Gutov <dgutov@yandex.ru>
On 15/01/2023 16:01, Eli Zaretskii wrote:
You will
see that where possible, just loading a TS mode modifies
auto-mode-alist if the tree-sitter support for that mode is available,
whereas for other modes auto-mode-alist is modified only when the mode
is actually turned on successfully for the first time. This is
because some of the TS modes have their own *.el files, whereas others
share a .el file with other modes, and so loading that file doesn't
necessarily means the user wants to use the tree-sitter based mode.
If we *are* going to do this (make all ts mode strictly optional), I
don't think either of this is a good idea: for a given foo-ts-mode, the
user might already have an auto-mode-alist entry configured with another
mode (third-party or not), and they will likely 'M-x foo-ts-mode' to try
how well it works (or doesn't).
Having auto-mode-alist modified automatically can come as a surprise
either way.
Note the this is different to having the auto-mode-alist entries set up
from the outset, because the user's alterations override those.
We can drop the auto-mode-alist alterations from ts modes altogether, to
bring them back when we do decide to enable them by default.
Like I said: this is not ideal. So I'm not surprised that whatever we
do, there can be usage scenarios where what we do will annoy someone.
That said:
. The proposed patch made many changes of auto-mode-alist
conditional where they previously were _un_conditional.
It also added some where there were none.
I submit
that this is less annoyance in the important use case where the
tree-sitter or the grammar library is not available. There are
indications that this situation will be frequent enough when Emacs
29.1 hits the street.
Like I said, either making them unconditional, or removing them, would
lead to better, more predictable behavior.
. I don't buy the assumption that customizations of auto-mode-alist
are frequent enough to make that an important factor in these
decisions, let alone suggest that users should always do that if
they want to try the *-ts-* modes seriously:
Why wouldn't they be frequent? It's the only way for the user to have
file format supported, where we don't support it OOTB.
The customization of auto-mode-alist might also happen for the user
automatically. When the user installs a third-party package, such as
json-mode, from ELPA, that modified auto-mode-alist through package
autoloads.
Having it modified again by 'M-x yaml-ts-mode', but only for the
duration of the current session, would be surprising and odd. If I were
a new user, I would be questioning both why the mode association
changed, and why it didn't persist between sessions.
- IME, auto-mode-alist is relatively rarely customized for modes
that are included in Emacs (e.g., I don't customize entries of
any such modes), for the simple reason that it is very rarely
needed.
I'm talking about modes which are not included in Emacs.
But having the association for .rb files rewritten when somebody invokes
'M-x ruby-ts-mode' would be weird too. It will make it a pain in the ass
for me to test ruby-ts-mode, for one thing.
Or js-mode -> js-ts-mode, or python-mode -> python-ts-mode. People
should be allowed to experiment without having to figure out how one can
undo an automated change like that.
- Customizing auto-mode-alist is not the easiest task, it
requires good knowledge of Emacs regexps and alists. So
asking anyone who wants to try using the tree-sitter modes to
do that is not the best idea from the POV of user-friendliness.
They will have to learn how to do that anyway, because the
auto-mode-alist alterations from your patch won't persist between sessions.
To make it easier, we could put examples in the Commentary of each ts
mode. That's something that has been a common practice with third-party
mode, so there are a lot of examples of this code out there anyway.
- OTOH, I'm quite sure that people who do already customize
auto-mode-alist for built-in modes are more advanced users and
will be able to overcome any problems that could be caused by
modifying auto-mode-alist as side effect of activating the
mode.
Adding elements to auto-mode-alist is easier than removing them.
. Last, but not least: I think someone who turns on a tree-sitter
mode in some buffer is much more likely to want to use that mode
in more than that single buffer than the other way around. And if
for some reason they are disappointed soon enough, just restarting
the Emacs session will get them back the old behavior. Which
again tells me that if we accept your proposal, we will annoy more
users (with the need to modify auto-mode-alist) than under my
proposal.
Someone who turns it on for the first time doesn't know yet whether they
want to use it or not. It hard to gauge the percentage of those who will.
And again, those who will want to, will have to learn how to deal with
auto-mode-alist anyway. For some modes that could be avoided with e.g.
(require 'yaml-ts-mode), but for others (e.g. python-ts-mode) it could
not. Why proliferate special cases?
- Make all tree-sitter modes optional, Eli Zaretskii, 2023/01/15
- Re: Make all tree-sitter modes optional, Dmitry Gutov, 2023/01/15
- Re: Make all tree-sitter modes optional, Theodor Thornhill, 2023/01/16
- Re: Make all tree-sitter modes optional, Eli Zaretskii, 2023/01/16
- Re: Make all tree-sitter modes optional,
Dmitry Gutov <=
- Re: Make all tree-sitter modes optional, Eli Zaretskii, 2023/01/16
- Re: Make all tree-sitter modes optional, Dmitry Gutov, 2023/01/16
- Re: Make all tree-sitter modes optional, Eli Zaretskii, 2023/01/16
- Re: Make all tree-sitter modes optional, Dmitry Gutov, 2023/01/17
- Re: Make all tree-sitter modes optional, Eli Zaretskii, 2023/01/17
- Re: Make all tree-sitter modes optional, Dmitry Gutov, 2023/01/17
- Re: Make all tree-sitter modes optional, Eli Zaretskii, 2023/01/17
- Re: Make all tree-sitter modes optional, Dmitry Gutov, 2023/01/17
- Re: Make all tree-sitter modes optional, Eli Zaretskii, 2023/01/17
- Re: Make all tree-sitter modes optional, Dmitry Gutov, 2023/01/17