[Top][All Lists]

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

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

From: Ergus
Subject: Re: [SPAM UNSURE] Maybe we're taking a wrong approach towards tree-sitter
Date: Fri, 30 Jul 2021 15:57:58 +0200

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

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

                                 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.

reply via email to

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