unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Yuan Fu <casouri@gmail.com>
To: Dmitry Gutov <dgutov@yandex.ru>
Cc: emacs-devel <emacs-devel@gnu.org>
Subject: Re: Status update of tree-sitter features
Date: Wed, 28 Dec 2022 16:23:21 -0800	[thread overview]
Message-ID: <D3CB232D-068D-4E10-9B80-D5F5E3E857D8@gmail.com> (raw)
In-Reply-To: <5d53b299-14e1-6f8b-58b3-7e16842d87a9@yandex.ru>



> On Dec 28, 2022, at 3:27 PM, Dmitry Gutov <dgutov@yandex.ru> wrote:
> 
> Hi Yuan,
> 
> I'm late to the party, so apologies if any of the following has been discussed before.
> 
> On 28/12/2022 11:44, Yuan Fu wrote:
> 
>> Here is the list, for your reference. Among all the features, I think assignment is “nice to have”, it’s fine to leave it out if there isn’t enough time. Same goes for key: it may or may not apply to a language.
>> Basic tokens:
>> delimiter       ,.;      (delimit things)
>> operator        == != || (produces a value)
>> bracket         []{}()
>> misc-punctuation
>> constant        true, false, null
>> number
>> keyword
>> comment         (includes doc-comments)
>> string          (includes chars and docstrings)
>> string-interpolation    f"text {variable}"
>> escape-sequence         "\n\t\\"
>> function                every function identifier
> 
> The description makes it easy to mistake for function definitions as well. Whereas the place where this category is used is function/method calls, right? And perhaps some other references to methods inside the code where the language parser can distinguish those from property access, etc.
> 
> If it's only about calls, maybe call this category funcall?

Function, property and variable are for every occurrence of them (the touted “consistent highlighting”). So there will be a bit of overlap between function, variable, and definition. 

> 
>> type                    every type identifier
>> property                a.b  <--- highlight b
> 
> Do we think it's a good idea to have 'property' in the default highlighting? IIUC the default level is 3.
> 
> Code like foo.bar is easy to understand at a glance, so it seems like it'll lead to a lot of repeated highlights. If 'function' (or 'funcall') is a level 4, maybe 'property' should be there too?

Ah yes property should be level 4, along with function and variable.

> 
> > variable                every variable identifier
> 
> 'variable', so far, seems like the least useful. When enabled, it lights up every bit of text that remained from other matchers -- because identifier are everywhere.

Yes, but apparently people want it ;-)

> There is this more advanced prior art for highlighting variables, by tracking the scopes using custom annotations, see locals.scm here:
> 
> https://tree-sitter.github.io/tree-sitter/syntax-highlighting#local-variables
> 
> What's displayed under "Result" would be really handy to have in Ruby.
> 
> It's nothing urgent, of course. Maybe for Emacs 30?

Yeah, this requires some non-trivial addition to the current fontification code.

> For Emacs 29, though, I would discourage the use of 'variable’.

It’s on level 4, meaning not enabled by default, so I think it’s fine.





  reply	other threads:[~2022-12-29  0:23 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-28  9:44 Status update of tree-sitter features Yuan Fu
2022-12-28 15:40 ` Mickey Petersen
2022-12-29  0:15   ` Yuan Fu
2022-12-28 23:27 ` Dmitry Gutov
2022-12-29  0:23   ` Yuan Fu [this message]
2022-12-29  0:34     ` Dmitry Gutov
2022-12-29  9:21       ` Yuan Fu
2022-12-29 16:38         ` Dmitry Gutov
2022-12-30 11:16           ` Yuan Fu
2022-12-30 23:41             ` Dmitry Gutov
2022-12-31 22:15               ` Yuan Fu
2022-12-29  3:28     ` Stefan Monnier
2022-12-29  9:23       ` Yuan Fu
2022-12-30 14:27       ` Jostein Kjønigsen
2022-12-30 15:37         ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=D3CB232D-068D-4E10-9B80-D5F5E3E857D8@gmail.com \
    --to=casouri@gmail.com \
    --cc=dgutov@yandex.ru \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).