all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Ihor Radchenko <yantar92@gmail.com>
To: Yuan Fu <casouri@gmail.com>
Cc: emacs-devel <emacs-devel@gnu.org>,
	 Theodor Thornhill <theo@thornhill.no>,
	 Stefan Monnier <monnier@iro.umontreal.ca>
Subject: Re: Recent updates to tree-sitter branch
Date: Mon, 03 Oct 2022 13:58:55 +0800	[thread overview]
Message-ID: <87lepxxxb4.fsf@localhost> (raw)
In-Reply-To: <67BF9BE5-4131-49CF-BB0A-687D51BB4870@gmail.com>

Yuan Fu <casouri@gmail.com> writes:

>>> Also bear in mind that the override flag can only be applied to the whole query, rather than individual captured nodes.
>> 
>> How does it change anything? I may be misunderstanding something---can
>> you provide some illustrative example clarifying whole query vs.
>> individual notes?
>
> What I meant is that, for font-lock-keywords, one can set override flag for each individual match:
>
> (string-regex font-lock-string-face t)
> (function-name-regexp font-lock-function-name-face nil)
> (class-name-regexp font-lock-type-face t)
> ...
>
> But for tree-sitter, a query contains many matches and the flag is set for the query. So if I want to use different override flag for different matches, I need to split them into two queries:
>
> (treesit-font-lock-rules
>  :language 'python
>  :override 'append
>  '((string) @python--treesit-fontify-string
>    ((string) @font-lock-doc-face
>     (:match "^\"\"\"" @font-lock-doc-face))
>    (interpolation (identifier) @font-lock-variable-name-face))
>
>  :language 'python
>  :override nil
>  '((function_definition
>     name: (identifier) @font-lock-function-name-face)
>
>    (class_definition
>     name: (identifier) @font-lock-type-face)
>
>    ;; Comment and string.
>    (comment) @font-lock-comment-face))

> That means if we use override=nil as default, it is very likely that users need to explicitly set override to t for the whole query, or split the query into separate parts. Nothing serious, but it seems less convenient.

What about allowing (@python--treesit-fontify-string 'append) to specify
the override?

> A real use-case for override is how I fontified Python strings above. I have three matches for (1) all strings (2) docstrings (3) variable names in string interpolations. IMO it’s intuitive and convenient for later more specific matches to override earlier more general matches.

The current convention in font-lock-keywords is exactly opposite -
earlier matches are more specific, and they are later not replaced by
later more general matches.

Also, for reference, I am currently developing parser-based
fontification for Org.

I am using a somewhat different approach (closer to font-lock-keywords):

((drawer property-drawer) ;; <- match node types
  (:begin-marker 'org-drawer t) ;; <- apply fontification to :begin-marker field inside 
  (:end-marker 'org-drawer t)) ;;  <- ...                    :end-marker ....
((headline inlinetask)
  (:title-line
   (if (org-element-match-property :archivedp) ;; <- Elisp matching of the node properties
       'org-archived
     (pcase (org-element-match-property :todo-type) ;; <- ....
       (`todo (when org-fontify-todo-headline 'org-headline-todo))
       (`done (when org-fontify-done-headline 'org-headline-done))
       (_ nil)))
   t)) ;; <- override
 ((bold italic underline verbatim code strike-through)
   (:full-no-blank '(face nil org-emphasis t))) ;; <- fontify contents of the matched node
   
Also, see https://github.com/yantar92/org/blob/feature/org-font-lock-element/lisp/org-font-lock.el#L574

From my experience re-implementing the vanilla fontification,
fontification order is important and may create subtle issues when not
designed carefully.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>



  reply	other threads:[~2022-10-03  5:58 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-25  4:27 Recent updates to tree-sitter branch Yuan Fu
2022-09-25  6:17 ` Ihor Radchenko
2022-09-26  8:35   ` Yuan Fu
2022-09-26  9:43     ` Ihor Radchenko
2022-09-27 22:28       ` Yuan Fu
2022-09-29  4:01         ` Ihor Radchenko
2022-09-30 21:03           ` Yuan Fu
2022-10-01  4:20             ` Ihor Radchenko
2022-10-02  3:46               ` Yuan Fu
2022-10-02  7:33                 ` Ihor Radchenko
2022-10-02 22:54                   ` Yuan Fu
2022-10-03  5:58                     ` Ihor Radchenko [this message]
2022-10-04 16:58                       ` Yuan Fu
2022-09-29 10:13 ` Aurélien Aptel

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

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

  git send-email \
    --in-reply-to=87lepxxxb4.fsf@localhost \
    --to=yantar92@gmail.com \
    --cc=casouri@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=theo@thornhill.no \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.