GNU bug report logs - #74610
31.0.50; Submitting mhtml-ts-mode, treesitter alternative to mhtml-mode

Previous Next

Full log

Message #67 received at 74610 <at> debbugs.gnu.org (full text, mbox):

From: Vincenzo Pupillo <v.pupillo <at> gmail.com>
To: Yuan Fu <casouri <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 74610 <at> debbugs.gnu.org,
 Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#74610: 31.0.50; Submitting mhtml-ts-mode,
 treesitter alternative to mhtml-mode
Date: Sun, 19 Jan 2025 18:09:31 +0100

[Message part 1 (text/plain, inline)]

Ciao Yuan,
In data sabato 18 gennaio 2025 02:37:53 Ora standard dell’Europa centrale, 
Yuan Fu ha scritto:
> > On Jan 14, 2025, at 1:41 PM, Vincenzo Pupillo <v.pupillo <at> gmail.com> wrote:
> > 
> > Ciao Yuan and Juri,
> > this is an updated version of mhtml-ts-mode.
> > I have tried to reduce as much as possible copies of parts of the major
> > modes from which it is derived.
> > To do this, I had to move some values that were assigned directly to
> > treesit's own variables  (in ccs-mode.el, in js.el, and in
> > html-ts-mode.el) into new variables.
> > I also added three new functions to treesit.el to make it easier to
> > combine
> > parts derived from the other major modes. So now any changes to these new
> > variables are directly reflected in the behavior of mhtml-ts-mode.
> > There are a few things I would like to highlight:
> > 1. treesit-font-lock-feature-lists are not defined per parser, so simply
> > merging the different lists will cause display differences from the
> > original major-modes; for example “function” is defined at level 3 in
> > css-ts-mode but at level 4 in js-ts-mode.
> 
> Yeah, that’s not pretty, I don’t have a good solution for now. Technically a
> major mode can use treesit-font-lock-recompute-features after
> treesit-major-mode-setup to do fine adjustments, but it’s ugly.
> > 2. treesit-defun-type-regexp has the same problem as treesit-font-lock-
> > feature-list, so I had to define it myself.
> 
> Maybe you can use treesit-thing-settings instead?
Ok, done.

> 
> > But other than that, it works pretty well.
> > 
> > IMHO, a global "list" where you can define "font-lock", "indent-list",
> > "font- lock-feature", etc. by language (perhaps with getter and setter
> > methods) might make it easier to define new multilingual major-modes. It
> > could improve the decoupling between multilingual major-modes and the
> > major-modes they are derived from. It could also better decouple the
> > internal implementation of treesit.el from the treesitter-based
> > major-modes.
> > 
> > Let me know what you think.
> 
> That’s what I had in mind. That’s also why I added a new variable
> treesit-aggregated-simple-imenu-settings instead of piggybacking on
> treesit-simple-imenu-settings. A separate variable is simpler to borrow
> settings from.
Yes, in this new patch I used treesit-aggregated-simple-imenu-settings.

> But I didn’t have time to think it though yet. (By language, or by mode and
> language? Should packages set it on load, or define a function that loads
> these settings? Etc.)
>
I would say by mode and language, both mhtml-ts mode and html-ts mode have the 
same primary parser. For the second question, I don't know. I don't have 
enough experience with it to know what the pros and cons are.

> Yuan

Vincenzo

[0001-Add-mhtml-ts-mode.patch (text/x-patch, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.