bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#64275: 30.0.50; [PATCH] Improve sigil font-lock match for elixir-ts-


From: Wilhelm Kirschbaum
Subject: bug#64275: 30.0.50; [PATCH] Improve sigil font-lock match for elixir-ts-mode
Date: Sun, 30 Jul 2023 09:53:15 +0200
User-agent: mu4e 1.9.3; emacs 30.0.50


Dmitry Gutov <dmitry@gutov.dev> writes:

On 25/06/2023 12:00, Wilhelm Kirschbaum wrote:
        "~" @font-lock-string-face
        (sigil_name) @elixir-ts-font-sigil-name-face
        (:match "^[rR]$" @elixir-ts-font-sigil-name-face))
       @font-lock-regexp-face
-     (sigil
-      "~" @font-lock-string-face
-      (sigil_name) @elixir-ts-font-sigil-name-face
-      quoted_start: _ @font-lock-string-face
-      quoted_end: _ @font-lock-string-face
-      (:match "^[HF]$" @elixir-ts-font-sigil-name-face)))
-
+     (sigil) @font-lock-string-face)

Hi Wilhelm!

Should we continue to use elixir-ts-font-sigil-name-face, though?


Hi :)

We still need to match only the sigil_name part, so can't use the
@font-lock-string-face as it will exclude the '~', therefore we need a custom font for the match. This is only true for ~r/regex content here/ and ~R/regex content here/, or variance ~r(regex content here) etc. where the font for the regex part is different than the font for the sigil
prefix.

Perhaps there is another way to both apply a font with
@font-lock-string-face and exclude it from the :match, but last time I
checked this was not possible.

With the new patch, it will continue highlight the sigil name ("r") in
regexps, but no in other sigil types (s/c/w).


Incorrect, just below there is a:

          (sigil) @font-lock-string-face)

without a match, so they will be highlighted, but just more generically
as we don't know which sigils the user might have assigned.

What's your opinion on that?

As a baseline it makes sense to me to apply font-lock-string-face to all sigils, as they can be user defined. Some are language core sigils, like the ~r and ~R sigils and then there are common library accepted
sigils like ~H and ~F which can effectively be seen as part of the
language, these can be added over time as we improve this mode. The initial ideas was to try and match a complete list, but won't work. Users can also define sigils in their projects, so its better to rely on
the grammar to tell us its a sigil.

I ran the current patch for over a month and feels correct.

Wilhelm






reply via email to

[Prev in Thread] Current Thread [Next in Thread]