Re: Re: Tree-sitter introduction documentation

Re: Re: Tree-sitter introduction documentation

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 1480 bytes --]

Ken writes:

> I wonder how well known this is among distro Emacs maintainers.  I did a
quick
> internet search and didn't find any indication that any distros have done
it
> yet.  Can anyone point me to an example?
>
> Ken

+1

I'm compiling emacs quite often in a container inside a VM, in order to
keep the number of libraries in my 'real' system under control. Using
containers, I'm able to generate .deb packages for different distros, which
is cool and I do mainly to test concepts I use in other contexts. So in a
sense, I'm packaging Emacs for myself.

Adding tree-sitter was straightforward for some bleeding-edge Debian based
distros, but not as easy for mainstream (e.g. Ubuntu focal, which is the
previous LTS). But that was only adding the library and compiling emacs
with the library.

I'm still struggling with the plug-ins... Questions I have are
1.- where will they sit at the end of the day?
2.- should I include *all* plug-ins or just the plug-ins I use (mainly
Python to get used to it)

The whole thing doesn't get better, because I'm also "playing" with Emacs
on macOS and there I'm still struggling with native compilation...

Anyhow, this is what makes things interesting and keeps my brain active.

/PA

-- 
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

[-- Attachment #2: Type: text/html, Size: 2049 bytes --]

Re: Re: Tree-sitter introduction documentation

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 1485 bytes --]

Philip Kaludercic <philipk@posteo.net> writes:

> My main worry with these changes, along with the popularity of LSP is
> that while they are technological improvements, they all happen at the
> deterioration of Emacs' introspectability, increasing the effort it
> takes for the user to make changes.  IIUC you can't reload a .el file or
> just a singular expression if you want to change how completion via
> Eglot or how imenu works via Tree Sitter.  A simple hack becomes a
> weekend project.  This is not an unconditional good.

That's a very good point. My .02 cents of experience with eglot/treesit:

while I'm happy it works now on my multi-OS setup and I can seamlessly
switch computers, it took me a lot of time to understand and duck-duck-go
and set up. On top of that, there are some things I still don't completely
understand and can't explore on the *scratch* buffer and/or slime.

And yes, I've also tried tree-sitter for Python on my Linux and it makes me
wonder what the real gain is, because I'm using the plain python-mode on
the other systems and I can't feel a compelling argument to switch.

At least that was the case with eglot ;-) and this is why I've stayed with
it.

Happy new year (the 365 days of it)
/PA

-- 
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

[-- Attachment #2: Type: text/html, Size: 2055 bytes --]

Re: Tree-sitter introduction documentation

[Eli Zaretskii]

> From: Pedro Andres Aranda Gutierrez <paaguti@gmail.com>
> Date: Sat, 31 Dec 2022 07:59:18 +0100
> 
> Philip Kaludercic <philipk@posteo.net> writes:
> 
> > My main worry with these changes, along with the popularity of LSP is
> > that while they are technological improvements, they all happen at the
> > deterioration of Emacs' introspectability, increasing the effort it
> > takes for the user to make changes.  IIUC you can't reload a .el file or
> > just a singular expression if you want to change how completion via
> > Eglot or how imenu works via Tree Sitter.  A simple hack becomes a
> > weekend project.  This is not an unconditional good.
> 
> That's a very good point. My .02 cents of experience with eglot/treesit:
> 
> while I'm happy it works now on my multi-OS setup and I can seamlessly switch computers, it took me a lot
> of time to understand and duck-duck-go and set up. On top of that, there are some things I still don't
> completely understand and can't explore on the *scratch* buffer and/or slime. 

Using technology that is implemented outside Emacs inevitably means we
have less transparency in Emacs itself for the related
functionalities.  However, hoping that everything can be implemented
by the Emacs project, and refusing to use external libraries for some
areas for that reason, is an evolutionary dead end for Emacs.  So we
have to do that to some degree where key technologies applicable to
Emacs features are available out there.  The job of the maintainers is
to identify those technologies, weigh their potential contributions to
future Emacs development, and decide whether those contributions
justify their use, with all the disadvantages in transparency that
will inevitably bring with it.

> And yes, I've also tried tree-sitter for Python on my Linux and it makes me wonder what the real gain is,
> because I'm using the plain python-mode on the other systems and I can't feel a compelling argument to
> switch.

Thank you for your feedback.  This is the reason we decided to keep
these modes separate and make trying the new tree-sitter based modes
as easy as possible.  This is also the kind of user feedback we will
need to collect when Emacs 29 is released, which will help us to
decide how to use tree-sitter based capabilities.  The decisions could
be different for different programming languages.