Eli writes:
> 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.

Just try M-x c-ts-mode and you'l get this message *four* times (side question, isn't one enough?)

⛔ Warning (treesit): Cannot activate tree-sitter, because tree-sitter library is not compiled with Emacs

Another question: If I can't use the command, wouldn't it be better if I had no access to it?

Best, /PA

PS: BTW, at this point, removing the 'Warning (treesit)' would leave a coherent message WRT the no entry sign, but that's another thread ;-)


On Sat, 21 Jan 2023 at 12:48, Eli Zaretskii <eliz@gnu.org> wrote:
> 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.


--
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run a leader-deposed hook here, but we can't yet