emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Make all tree-sitter modes optional


From: Eli Zaretskii
Subject: Re: Make all tree-sitter modes optional
Date: Sat, 21 Jan 2023 13:48:50 +0200

> From: Pedro Andres Aranda Gutierrez <paaguti@gmail.com>
> Date: Sat, 21 Jan 2023 12:30:26 +0100
> Cc: emacs-devel@gnu.org
> 
> Eli writes:
> > Why would it confuse?  You also have there stuff like w32-win.el.gz,
> > which is used only on MS-Windows, and other files that are not
> > necessarily for your configuration.  This is not a problem, and
> > shouldn't be one.
> 
> I don't know, maybe for me there is a difference between the OS specific 
> stuff, tree-sitter and other stuff in
> Emacs:

It is nothing new in Emacs: we provide many packages, some of which
are specific to platforms other than yours, some others need optional
libraries that you don't necessarily have, etc.

> tree-sitter modes 'compete' with 'regular' modes and if I don't have 
> tree-sitter activated at compile time, it
> can be misleading to see those files there

I disagree it should mislead anyone, and let's leave it at that.

> and 'sub-optimal' (to say the least) to get a message that you
> can't use them.

What message?  I asked to show these messages before, and I didn't see
your answer to that question.  We don't intend to have Emacs show any
such messages just because you don't have tree-sitter installed.

> OS related stuff is different in the sense that, well, if I'm on a Linux 
> system and try to use (you say the
> OS)-specific features, it is natural that I get a 'wake-up' message there and 
> stop trying to do things that make
> no sense. 

Same thing if you use a Lisp package which requires an optional
library you don't have installed or if you use Emacs which wasn't
built with support for that library.  Examples: GnuTLS, HarfBuzz,
librsvg, sqlite3, etc.

> As for the rest, having dormant features that _work_ (or are WIP with a level 
> of maturity enough to be in
> master) and only wait for me to test them and activate them if they help me 
> in my day-to-day interactions
> with Emacs, of course, put 10^n n->infinity of those in Emacs, no problem.
> 
> In that sense, if there was a way to disregard *-ts-*.el files in ELC/ELN 
> compilation and installation when I
> compile Emacs _without_ tree-sitter support, the whole picture would be (once 
> again, IMvHO) much more
> coherent.

We don't disregard any Lisp files.  When Emacs builds, it compiles all
the files in the source tree.  A release tarball comes with *.elc
files already compiled, and *.eln files will only be produced if you
actually load the corresponding *.el package.  So I see no problem
here.



reply via email to

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