all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Yuan Fu <casouri@gmail.com>
To: Denis Zubarev <dvzubarev@yandex.ru>
Cc: Dmitry Gutov <dmitry@gutov.dev>, Eli Zaretskii <eliz@gnu.org>,
	"67061@debbugs.gnu.org" <67061@debbugs.gnu.org>
Subject: bug#67061: [PATCH] Improve syntax highlighting for python-ts-mode
Date: Sat, 16 Dec 2023 17:10:24 -0800	[thread overview]
Message-ID: <8915940C-F69C-4CAE-80E8-4F70C5753061@gmail.com> (raw)
In-Reply-To: <7371702772641@mail.yandex.ru>



> On Dec 16, 2023, at 4:26 PM, Denis Zubarev <dvzubarev@yandex.ru> wrote:
> 
> Sorry for the delayed response.
>  > For many Emacs users, they want a quieter or even minimal fontification.
>  I'm not against it. I just think that highlighting of an interpolation
> as a string is wrong. Is it possible to set quiet fontification in
> emacs-lisp mode, in such a way that `keywords' in doc-strings were
> fontified as a doc-string itself? I think it is similar to
> interpolation, it serves the purpose of separating different semantic
> elements from each other. IMHO, users who like quiet levels will benefit
> from interpolation highlighted differently.

I definitely can see your point, and it makes a lot of sense. I don’t really know people who want quieter fontification wants (probably both approach has their supporters) so can’t speak for them. But in general, I think it wouldn’t hurt to have the option.

>  > Instead of the third level, the check should use the value
> > treesit-font-lock-level. And it should check for each level smaller than
> > or equal to treesit-font-lock-level.
>  Done.

Thank you for your hard work! I’m just here talking and you went ahead and did all the work :-)

>  > Non-essential fontification like "var" shouldn't be
> > activated at that level. So I suggest to put it in the variable feature,
> > along with many other non-essential fontifications. (Variable feature is
> > placed at level 4.)
>  I added a new feature variable-definition for variables defined for local scopes and put it on the 3rd level.
> I also added rules to variable-definition feature for variables in list
> comprehension ( [var+1 for var in []] ) and as_pattern (with T as var:,
> except E as var:, case str() as var:).
>  I've noticed that vars in `for var1, (var2, var3) in []:` are highlighted by the rule from the assignment feature (specifically `pattern_list`, `tuple_pattern`).
> It seems easy to fix `pattern_list`, but not so easy for
> `tuple_pattern`, since this node may occur recursively.
> I didn't touch these rules for now.

Ok, makes sense.

>    Summary for all changes in the patch.
>  New feature variable-definition:
> `for var in range(3)`
> `[var+1 for var in []]`
> `with T as var:`
> `except E as var:`
> `case str() as var:`
> highlight var as font-lock-variable-name-face
>  assignment feature:
> var := 3 (named_expression)
> var *= 3 (augmented_assignment)
> Highlight var as font-lock-variable-name-face.
>  Make list_splat_pattern query more precise.
> list_splat_pattern may appear not only in assignments: var, *rest = call(),
> but in the parameter list too: def f(*args).
> Highlight args only for the first case in assignment feature.
>   type feature:
> Fontify built-ins (dict,list,etc.) as types when they are used in type hints.
> support nested union types, for example `Lvl1 | Lvl2[Lvl3[Lvl3], Lvl2]`.
> This structure is represented via nesting binary_operator and subscript nodes in the grammar.
> Function python--treesit-fontify-union-types iterates over all children and highlight identifier nodes.
>  Fontify base class names in the class definition: class Temp(Base1, pack0.Base2):
> Fontify class patterns in case statement: case [TempC() | bytes(b)]:
> Highlight the second argument as a type in isinstance/issubclass call:
> isinstance(var2, (str, dict, Type1)); issubclass(var1, int|str)
>  For all dotted names of a type highlight only the last part of the name,
> e.g. collections.abc.Iterator.
>   decorator feature:
> Highlight dotted names: @pytest.mark.skip
> Function python--treesit-fontify-dotted-decorator iterates over all nested attribute nodes and highlight identifier nodes.
>  When font-lock-level is set 4, `skip` had function-call face in: @pytest.mark.skip(reason='t')
> Add `:override t` to decorator feature to override function-call face.
>   string feature:
> Enable interpolation highlighting only if string-interpolation is
> presented on the enabled levels of treesit-font-lock-feature-list.
> Fix fontification of strings inside of f-strings interpolation,
> e.g. for f"beg {'nested'}" - 'nested' was not fontified as string.
>   function feature:
> Do not override the face of builtin functions (all, bytes etc.) with
> the function call face
>   keyword feature:
> Add "is not"  to the `python--treesit-keywords` list.

Thanks. I think the only thing that’s still up to discussion is the variable-definition rules. Others can be merged to emacs-29.

Yuan




  reply	other threads:[~2023-12-17  1:10 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-11  2:21 bug#67061: [PATCH] Improve syntax highlighting for python-ts-mode Denis Zubarev
2023-11-11  7:32 ` Eli Zaretskii
2023-11-11 10:52   ` Denis Zubarev
2023-11-11 11:00     ` Eli Zaretskii
2023-11-11 12:09       ` Denis Zubarev
2023-11-26  2:12       ` Dmitry Gutov
2023-11-15 13:28   ` Eli Zaretskii
2023-11-25  9:35     ` Eli Zaretskii
2023-11-26  2:17       ` Dmitry Gutov
2023-11-29 14:05         ` Eli Zaretskii
2023-12-09  0:39           ` Denis Zubarev
2023-12-09  7:32             ` Eli Zaretskii
2023-12-10 10:16               ` Yuan Fu
2023-12-09 18:18             ` Dmitry Gutov
2023-12-10 12:04               ` Denis Zubarev
2023-12-11  0:00                 ` Dmitry Gutov
2023-12-11  7:10                   ` Yuan Fu
2023-12-11 12:02                     ` Dmitry Gutov
2023-12-12  1:18                     ` Denis Zubarev
2023-12-12  8:24                       ` Yuan Fu
2023-12-13  0:44                         ` Dmitry Gutov
2023-12-13  3:49                           ` Yuan Fu
2023-12-13 18:28                             ` Dmitry Gutov
2023-12-14  5:54                               ` Yuan Fu
2023-12-14 11:51                                 ` Dmitry Gutov
2023-12-17  1:07                                   ` Yuan Fu
2023-12-17 21:36                                     ` Dmitry Gutov
2023-12-23 21:46                                     ` Denis Zubarev
2023-12-16 13:03                                 ` Eli Zaretskii
2023-12-17  1:56                               ` Denis Zubarev
2023-12-17 23:38                                 ` Dmitry Gutov
2023-12-13 11:52                         ` Eli Zaretskii
2023-12-17  0:26                         ` Denis Zubarev
2023-12-17  1:10                           ` Yuan Fu [this message]
2023-12-17  2:07                             ` Denis Zubarev
2023-12-23  9:42                               ` Eli Zaretskii
2023-12-30 10:53                                 ` Denis Zubarev
2023-12-30 11:19                                   ` Eli Zaretskii
2023-12-18  0:25                           ` Dmitry Gutov
2023-12-19  0:14                             ` Denis Zubarev
2023-12-20 23:34                               ` Dmitry Gutov
2023-12-21  7:04                                 ` Yuan Fu
2023-12-23 21:45                                 ` Denis Zubarev
2024-01-01 17:42                                   ` Dmitry Gutov
2024-01-09 20:03                                     ` Eli Zaretskii
2024-01-20  9:08                                       ` Eli Zaretskii
2024-01-27  9:49                                         ` Eli Zaretskii
2024-01-27 10:47                                           ` Denis Zubarev
2024-01-27 11:30                                             ` Eli Zaretskii
2023-12-13 21:16         ` Stefan Kangas
2023-12-14  1:31           ` Dmitry Gutov
2023-12-14 22:49             ` Stefan Kangas
2023-12-15  7:14               ` Yuan Fu
2023-12-11  6:53 ` Yuan Fu

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=8915940C-F69C-4CAE-80E8-4F70C5753061@gmail.com \
    --to=casouri@gmail.com \
    --cc=67061@debbugs.gnu.org \
    --cc=dmitry@gutov.dev \
    --cc=dvzubarev@yandex.ru \
    --cc=eliz@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 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.