Re: [SPAM UNSURE] Maybe we're taking a wrong approach towards tree-sitter

[Ergus <spacibba@aol.com>]

On Fri, Jul 30, 2021 at 03:30:42PM +0200, Arthur Miller wrote:
>�scar Fuentes <ofv@wanadoo.es> writes:
>
>> Arthur Miller <arthur.miller@live.com> writes:
>>
>>> I undestand that having specialized regex matcher is more efficient than
>>> some generalized regular matcher current font-locking in Emacs relies
>>> upon, but is it *that* more efficient to be worth the extra troubles?
>>
>> AFAIU this is not about efficience, but mainly about correctness (modern
>> languages are increasingly more difficult to analyze)
>
>Ok, I understand, and I can buy that one. Question is if it is still
>worth just for the syntax hightlight and indentation? If I get some
>spurious color here or there sometimes not colored, do I care?
>

Yes, we care. Syntax highlight for an editor is a basic feature in 2021.

>Can that syntax tree of TS be exposed to lisp and used for some other
>purposes,

This is the idea. use the tree for navigations like up-list or
goto-defun for example. Maybe not the tree directly, but the information
it provides (maybe calling TS function wrappers or setting the TS
information as text properties).

>or is it just internal to TS and only output we see is some
>colors on the screen?
>
How we use it is more a design choice. We can access the tree
information with the TS api or we can just put the tree's information as
text properties... imagination is the limit ;)

>>                                                       and also about
>> decreasing the maintenance load.
>Sure, but it is also a limitation. If Emacs will rely on TS maintainers
>to create new grammars and update existing ones when language changes,
>it means Emacs users will have to wait for changes until they are
>fixed upstream, similar as how gnu/linux distros work regarding
>packaging. Of course, a user who wish to modify or introduce new
>language can always rely on old font-lock or go through pain of TS
>toolilng based on JS and custom tools. Lisp frontend to that toolchain
>can probably be developed but that is even more work.
>
Sincerely; create a grammar for TS is much simpler than create a mode
with font-lock, navigation commands, indentation rules and some
flymake. All the modes with TS will be a bit more consistent in colors
and keybindings (now we have modes where all commands use different
prefixes, or lacking navigation or with different indentation
customs. So using them is like learning different editors for every
language)

>>                                  In the process, Emacs gets support for
>> some new languages too.
>
>Yes, it is always nice I guess :). Is there really demand for some
>language currently provided in TS and not in Emacs?
>

Indeed. As I mentioned before web developers are using VScode or neovim
because Angular, React, Nodejs and Python are painfully supported
(compared to VScode or Sublime). Rust is very limited supported in
emacs, so users rely on external packages like rust-mode, elpy or
anaconda that introduce different bindings, collisions and require some
complex setups for the basics.

>I don't know, I am maybe overly sceptical to TS; I don't mean it is a
>bad package, and I am sure it has it's place in other editors, I am just
>not sure how it fits in Emacs where everything is easily configurable
>and extensible.
>
It is just a good trade-off configurable enough for 99% of the use
cases. Unless we expect all the users to be advanced lisp hackers to
customize their fontlocking, indentation and navigation functions for
every single prog-mode.