From: Eli Zaretskii <eliz@gnu.org>
To: jostein@kjonigsen.net
Cc: monnier@iro.umontreal.ca, casouri@gmail.com, dgutov@yandex.ru,
emacs-devel@gnu.org
Subject: Re: Status update of tree-sitter features
Date: Fri, 30 Dec 2022 17:37:06 +0200 [thread overview]
Message-ID: <83wn686gyl.fsf@gnu.org> (raw)
In-Reply-To: <82501cb9-f51c-da5d-9f10-247d99012cb1@secure.kjonigsen.net> (message from Jostein Kjønigsen on Fri, 30 Dec 2022 15:27:16 +0100)
> Date: Fri, 30 Dec 2022 15:27:16 +0100
> Cc: Dmitry Gutov <dgutov@yandex.ru>, emacs-devel <emacs-devel@gnu.org>
> From: Jostein Kjønigsen <jostein@secure.kjonigsen.net>
>
> I know that some people prefer "sparse" syntax-highlighting, while
> others prefer more "complete" highlighting. Personally, I value being
> able to see function invocations, and love how tree-sitter makes that
> easy to highlight.
>
> As long as we have ways to accommodate both needs ("fruit salad" vs more
> sparse fontification) I'm going to be happy, and we kind of already have
> that through font-lock levels in the modes already.
>
> That said, some of the tree-sitter based major modes (half? most?)
> currently highlight function-invocations on level 3. If we are to make
> everyone happy, we need to make changes to that, and move that to 4.
>
> Which leads me to my main point here.
>
> Emacs 29 release is near. We should seriously limit the amount of
> changes we apply in order to fix the things we need.
>
> Deciding at this point to rework all the features, which features we
> should have, how they can be enabled/disabled, and what
> enabling/disabling those should entail in practice... That's essentially
> suggestion we rewrite all those tree-sitter-based major-modes.
>
> I think a much more realistic strategy at this point is:
>
> - to aim for what concrete things should be fontified at level 3 and 4
> (default vs max). We already know 1 thing we want to change here.
>
> - ensure the major-modes adhere to this with a minimum of changes in the
> existing code.
>
> - and most importantly: leave the discussion about adding the ability
> for users to enable/disable specific features, and how that should work
> in practice (overlap, presedence, etc) for Emacs 30.
I agree. Please post concrete proposals for making modes consistent
regarding the default fontification level.
prev parent reply other threads:[~2022-12-30 15:37 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
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 [this message]
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=83wn686gyl.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=casouri@gmail.com \
--cc=dgutov@yandex.ru \
--cc=emacs-devel@gnu.org \
--cc=jostein@kjonigsen.net \
--cc=monnier@iro.umontreal.ca \
/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).