[Top][All Lists]

[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: Tue, 17 Jan 2023 21:21:03 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2

On 17/01/2023 21:03, Eli Zaretskii wrote:

Both.  I mention auto-mode-alist as the last alternative, for those
who are fine with going that way.  It isn't black-and-white.

But it's either that, or "turn them on manually", right? That would also
work with my proposal.

Your proposal makes it harder by making it necessary to mess with
auto-mode-alist.  I hope we can make it easier, at least in many/most
cases.  That is a non-negligible advantage from my POV.

The userbase I'm familiar with has been messing with auto-mode-alist for decades. To make it easier, people have been adding the necessary lines to documentation: either to the repository's README, or to package's Commentary. So the user could take it from there.

Similarly, we can add such line to the Commentary of every ts mode, or even to the major mode docstrings.

We also have merged use-package to Emacs. It makes the same operation a little easier, though not by much:

(use-package js
  :mode ("\\.js\\'" . js-ts-mode))

Either way, there are a lot of examples of this kind of configuration out there.

That's specific to js-ts-mode (and one other, I think) because they
share the .el file with a non-tree-sitter mode.  If there's a
reasonable way to give them separate files, things would be easier.

Right. If they were in separate files, then we could write the doc with
suggestions to merely violate the standard recommendation of avoiding
'require' in the init script.

But this is not a documentation issue, first and foremost.

Inconsistencies in design often turn up as documentation issues later.

I didn't design js.el that way.  I just assumed there were good
reasons for that and tried to adapt as best I could.

I think the design is fine, but whatever solution we choose should be compatible with it.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]