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