GNU bug report logs - #67246
30.0.50; elixir-ts-mode uses faces inconsistently

Previous Next

To reply to this bug, email your comments to 67246 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Andrey Listopadov <andreyorst <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; elixir-ts-mode uses faces inconsistently
Date: Fri, 17 Nov 2023 22:50:58 +0300

I've upgraded from elixir-mode to elixir-ts-mode and noticed that the
latter uses faces rather inconsistently.

For example, the =font-lock-keyword-face= is used for both keywords and
method calls, as well as for parentheses.  The
=font-lock-function-name-face= is used both for function definitions,
parameter names, and calls.  Some calls use the
=font-lock-keyword-face=, for example the call to `raise'.  The
=font-lock-type-face= is used both for types and =:symbols=.

All of that basically makes Elixir code mostly use 2 colors.
Additionally, it makes impossible selectively disabling highlighting, as
disabling the function call highlighting will disable the function
definition highlighitng an so on.

I believe, Emacs 29 introduced a lot of faces for all kinds of
situations possible in Tree-sitter generated AST, so perhaps the fix is
to use them more semantically, rather than for good looks.



In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.38, cairo version 1.17.8) of 2023-11-08 built on toolbox
Repository revision: bf9cbc2354124a1e9eb3327007468ba384ba2945
Repository branch: master
System Description: Fedora Linux 38 (Container Image)

Configured using:
 'configure --without-compress-install --with-native-compilation=aot
 --with-pgtk --with-mailutils --with-xwidgets
 --prefix=/var/home/alist/.local'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY
PDUMPER PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER XIM XWIDGETS GTK3 ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: mu4e:main

Minor modes in effect:
  global-git-commit-mode: t
  magit-auto-revert-mode: t
  mu4e-search-minor-mode: t
  mu4e-update-minor-mode: t
  mu4e-context-minor-mode: t
  electric-pair-mode: t
  savehist-mode: t
  delete-selection-mode: t
  pixel-scroll-precision-mode: t
  global-auto-revert-mode: t
  repeat-mode: t
  vertico-mode: t
  marginalia-mode: t
  corfu-popupinfo-mode: t
  global-corfu-mode: t
  global-region-bindings-mode: t
  recentf-mode: t
  gcmh-mode: t
  override-global-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  context-menu-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: t
  buffer-read-only: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  overwrite-mode: overwrite-mode-binary

Load-path shadows:
/var/home/alist/.config/emacs/elpa/transient-20231103.2312/transient hides /var/home/alist/.local/share/emacs/30.0.50/lisp/transient
/var/home/alist/.config/emacs/elpa/modus-themes-20231031.716/theme-loaddefs hides /var/home/alist/.local/share/emacs/30.0.50/lisp/theme-loaddefs

Features:
(shadow face-remap emacsbug mu4e mu4e-org ob-fennel fennel-proto-repl
fennel-mode inf-lisp xref magit-bookmark magit-submodule magit-blame
magit-stash magit-reflog magit-bisect magit-push magit-pull magit-fetch
magit-clone magit-remote magit-commit magit-sequence magit-notes
magit-worktree magit-tag magit-merge magit-branch magit-reset
magit-files magit-refs magit-status magit magit-repos magit-apply
magit-wip magit-log which-func imenu magit-diff smerge-mode diff
diff-mode git-commit log-edit pcvs-util add-log magit-core
magit-autorevert magit-margin magit-transient magit-process with-editor
magit-mode transient magit-git magit-base magit-section cursor-sensor
crm project ob-lua ob-shell shell org ob ob-tangle ob-ref ob-lob
ob-table ob-exp org-macro org-src ob-comint org-pcomplete pcomplete
org-list org-footnote org-faces org-entities ob-emacs-lisp ob-core
ob-eval org-cycle org-table org-keys oc org-loaddefs find-func mu4e-main
mu4e-view gnus-art mm-uu mml2015 mm-view mml-smime smime gnutls dig
gnus-sum gnus-group gnus-undo gnus-start gnus-dbus gnus-cloud nnimap
nnmail mail-source utf7 nnoo parse-time iso8601 gnus-spec gnus-int
gnus-range gnus-win gnus nnheader range cal-menu calendar cal-loaddefs
mu4e-headers mu4e-compose mu4e-draft mu4e-actions smtpmail mu4e-search
mu4e-lists mu4e-bookmarks mu4e-mark mu4e-message shr pixel-fill kinsoku
url-file svg dom flow-fill hl-line mu4e-contacts mu4e-update
mu4e-folders mu4e-server mu4e-context mu4e-vars mu4e-helpers mu4e-config
bookmark ido message sendmail yank-media puny dired dired-loaddefs
rfc822 mml mml-sec epa epg rfc6068 epg-config gnus-util time-date
mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util
ietf-drums mail-prsvr mailabbrev mail-utils gmm-utils mailheader
vertico-directory mule-util highlight-defined advice noutline outline
elec-pair isayt disp-table hideshow hl-todo savehist delsel pixel-scroll
cua-base autorevert filenotify repeat vertico marginalia corfu-popupinfo
cape corfu compat region-bindings recentf tree-widget gcmh init proxy
gsettings s gvariant parsec dash zig-compilation-mode
fennel-compilation-mode clojure-compilation-mode derived compile
text-property-search server ediff ediff-merg ediff-mult ediff-wind
ediff-diff ediff-help ediff-init ediff-util sql-indent sql view
thingatpt comint ansi-osc ring zig-mode reformatter ansi-color ol
org-fold org-fold-core org-compat org-version org-macs format-spec blog
use-package-delight formfeed modus-vivendi-theme modus-themes dbus xml
common-lisp-modes novice cus-edit pp cus-load wid-edit font mode-line
messages defaults edmacro kmacro functions use-package-bind-key bind-key
local-config delight comp comp-cstr warnings icons rx use-package-ensure
cl-extra help-mode use-package-core early-init finder-inf blog-autoloads
cape-autoloads clj-decompiler-autoloads clj-refactor-autoloads
cider-autoloads clojure-mode-autoloads common-lisp-modes-autoloads
consult-autoloads corfu-terminal-autoloads corfu-autoloads
csv-mode-autoloads delight-autoloads dumb-jump-autoloads eat-autoloads
elfeed-autoloads expand-region-autoloads fennel-mode-autoloads
gcmh-autoloads geiser-guile-autoloads geiser-autoloads gnugo-autoloads
ascii-art-to-unicode-autoloads gsettings-autoloads gvariant-autoloads
highlight-defined-autoloads hl-todo-autoloads inflections-autoloads
isayt-autoloads jdecomp-autoloads lsp-java-autoloads
lsp-metals-autoloads dap-mode-autoloads lsp-docker-autoloads
bui-autoloads lsp-treemacs-autoloads lsp-mode-autoloads f-autoloads
lua-mode-autoloads marginalia-autoloads markdown-mode-autoloads
message-view-patch-autoloads magit-autoloads pcase
magit-section-autoloads git-commit-autoloads modus-themes-autoloads
mu4e-alert-autoloads alert-autoloads log4e-autoloads gntp-autoloads
multiple-cursors-autoloads orderless-autoloads org-modern-autoloads
org-tree-slide-autoloads ox-hugo-autoloads
package-lint-flymake-autoloads package-lint-autoloads paredit-autoloads
parsec-autoloads parseedn-autoloads parseclj-autoloads
phi-search-autoloads popon-autoloads popup-autoloads puni-autoloads
easy-mmode racket-mode-autoloads region-bindings-autoloads
request-autoloads scala-mode-autoloads separedit-autoloads
edit-indirect-autoloads sesman-autoloads sly-autoloads spinner-autoloads
sql-indent-autoloads tomelr-autoloads transient-autoloads
treemacs-autoloads cfrs-autoloads posframe-autoloads ht-autoloads
hydra-autoloads lv-autoloads pfuture-autoloads ace-window-autoloads
avy-autoloads s-autoloads dash-autoloads vertico-autoloads
vundo-autoloads with-editor-autoloads info compat-autoloads
xpm-autoloads queue-autoloads yaml-autoloads yaml-mode-autoloads
yasnippet-autoloads zig-mode-autoloads reformatter-autoloads package
browse-url url url-proxy url-privacy url-expand url-methods url-history
url-cookie generate-lisp-file url-domsuf url-util mailcap url-handlers
url-parse auth-source cl-seq eieio eieio-core cl-macs password-cache
json subr-x map byte-opt gv bytecomp byte-compile url-vars cl-loaddefs
cl-lib rmc iso-transl tooltip cconv eldoc paren electric uniquify
ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/pgtk-win
pgtk-win term/common-win pgtk-dnd touch-screen tool-bar dnd fontset
image regexp-opt fringe tabulated-list replace newcomment text-mode
lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch
easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads xwidget-internal dbusbind
inotify dynamic-setting system-font-setting font-render-setting cairo
gtk pgtk lcms2 multi-tty move-toolbar make-network-process
native-compile emacs)

Memory information:
((conses 16 672577 585595) (symbols 48 39874 485)
 (strings 32 183934 60222) (string-bytes 1 5724204) (vectors 16 69084)
 (vector-slots 8 1236810 764574) (floats 8 489 1785)
 (intervals 56 649 178) (buffers 992 11))

-- 
Andrey Listopadov

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

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Andrey Listopadov <andreyorst <at> gmail.com>, 67246 <at> debbugs.gnu.org,
 Wilhelm H Kirschbaum <wkirschbaum <at> gmail.com>
Subject: Re: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Date: Sat, 18 Nov 2023 03:36:26 +0200

On 17/11/2023 21:50, Andrey Listopadov wrote:
> 
> I've upgraded from elixir-mode to elixir-ts-mode and noticed that the
> latter uses faces rather inconsistently.
> 
> For example, the =font-lock-keyword-face= is used for both keywords and
> method calls, as well as for parentheses.  The
> =font-lock-function-name-face= is used both for function definitions,
> parameter names, and calls.  Some calls use the
> =font-lock-keyword-face=, for example the call to `raise'.  The
> =font-lock-type-face= is used both for types and =:symbols=.
> 
> All of that basically makes Elixir code mostly use 2 colors.
> Additionally, it makes impossible selectively disabling highlighting, as
> disabling the function call highlighting will disable the function
> definition highlighitng an so on.
> 
> I believe, Emacs 29 introduced a lot of faces for all kinds of
> situations possible in Tree-sitter generated AST, so perhaps the fix is
> to use them more semantically, rather than for good looks.

Thanks for the report. Wilhelm, could you look into this? If you have time.

Speaking of new faces, we added font-lock-function-call-face that can be 
used for function calls, while font-lock-function-name-face stays used 
on definitions.

For parens, if one wanted to highlight them at all, 
font-lock-bracket-face could be used. Though it's probably better to 
leave them to the 4th feature level (see js-ts-mode as an example). 
elixir-ts-mode currently defines 3 levels.

For levels, we've currently settled on the scheme that function calls 
and property lookups go to the 4th level of highlighting, whereas the 
default is 3. This is all tweakable by the individual user, but I think 
it's better to stay consistent between the modes.

Finally, I see that font-lock-function-name-face ends up being used for 
parameters (as Andrey mentioned) and local variables as well. That's not 
great; probably a query that ended up matching too widely. We prefer to 
use font-lock-variable-name-face (for parameter declarations) or 
font-lock-variable-use-face for such identifiers. Though it can be hard 
to reliably distinguish them in a dynamic language, so as far as I'm 
concerned, they could stay non-highlighted (the uses, that is; the 
declarations are usually easy to find using queries).

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

From: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: Andrey Listopadov <andreyorst <at> gmail.com>, 67246 <at> debbugs.gnu.org
Subject: Re: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Date: Sat, 18 Nov 2023 09:50:48 +0200

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

On Sat, Nov 18, 2023 at 3:36 AM Dmitry Gutov <dmitry <at> gutov.dev> wrote:

> On 17/11/2023 21:50, Andrey Listopadov wrote:
> >
> > I've upgraded from elixir-mode to elixir-ts-mode and noticed that the
> > latter uses faces rather inconsistently.
> >
> > For example, the =font-lock-keyword-face= is used for both keywords and
> > method calls, as well as for parentheses.  The
> > =font-lock-function-name-face= is used both for function definitions,
> > parameter names, and calls.  Some calls use the
> > =font-lock-keyword-face=, for example the call to `raise'.  The
> > =font-lock-type-face= is used both for types and =:symbols=.
> >
> > All of that basically makes Elixir code mostly use 2 colors.
> > Additionally, it makes impossible selectively disabling highlighting, as
> > disabling the function call highlighting will disable the function
> > definition highlighitng an so on.
> >
> > I believe, Emacs 29 introduced a lot of faces for all kinds of
> > situations possible in Tree-sitter generated AST, so perhaps the fix is
> > to use them more semantically, rather than for good looks.
>
> Thanks for the report. Wilhelm, could you look into this? If you have time.
>
> Speaking of new faces, we added font-lock-function-call-face that can be
> used for function calls, while font-lock-function-name-face stays used
> on definitions.
>
> For parens, if one wanted to highlight them at all,
> font-lock-bracket-face could be used. Though it's probably better to
> leave them to the 4th feature level (see js-ts-mode as an example).
> elixir-ts-mode currently defines 3 levels.
>
> For levels, we've currently settled on the scheme that function calls
> and property lookups go to the 4th level of highlighting, whereas the
> default is 3. This is all tweakable by the individual user, but I think
> it's better to stay consistent between the modes.
>
> Finally, I see that font-lock-function-name-face ends up being used for
> parameters (as Andrey mentioned) and local variables as well. That's not
> great; probably a query that ended up matching too widely. We prefer to
> use font-lock-variable-name-face (for parameter declarations) or
> font-lock-variable-use-face for such identifiers. Though it can be hard
> to reliably distinguish them in a dynamic language, so as far as I'm
> concerned, they could stay non-highlighted (the uses, that is; the
> declarations are usually easy to find using queries).
>

Thanks for the detailed explanation. It's unfortunate timing, because I
published a rework of the faces on MELPA so long and a few people are
trying it out. It is a total rework using the faces a bit better.  I can
submit the patch later today and start the conversation from there?

Wilhelm

[Message part 2 (text/html, inline)]

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

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>
Cc: Andrey Listopadov <andreyorst <at> gmail.com>, 67246 <at> debbugs.gnu.org
Subject: Re: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Date: Mon, 20 Nov 2023 03:50:23 +0200

On 18/11/2023 09:50, Wilhelm Kirschbaum wrote:
> 
> On Sat, Nov 18, 2023 at 3:36 AM Dmitry Gutov <dmitry <at> gutov.dev 
> <mailto:dmitry <at> gutov.dev>> wrote:
> 
>     On 17/11/2023 21:50, Andrey Listopadov wrote:
>      >
>      > I've upgraded from elixir-mode to elixir-ts-mode and noticed that the
>      > latter uses faces rather inconsistently.
>      >
>      > For example, the =font-lock-keyword-face= is used for both
>     keywords and
>      > method calls, as well as for parentheses.  The
>      > =font-lock-function-name-face= is used both for function definitions,
>      > parameter names, and calls.  Some calls use the
>      > =font-lock-keyword-face=, for example the call to `raise'.  The
>      > =font-lock-type-face= is used both for types and =:symbols=.
>      >
>      > All of that basically makes Elixir code mostly use 2 colors.
>      > Additionally, it makes impossible selectively disabling
>     highlighting, as
>      > disabling the function call highlighting will disable the function
>      > definition highlighitng an so on.
>      >
>      > I believe, Emacs 29 introduced a lot of faces for all kinds of
>      > situations possible in Tree-sitter generated AST, so perhaps the
>     fix is
>      > to use them more semantically, rather than for good looks.
> 
>     Thanks for the report. Wilhelm, could you look into this? If you
>     have time.
> 
>     Speaking of new faces, we added font-lock-function-call-face that
>     can be
>     used for function calls, while font-lock-function-name-face stays used
>     on definitions.
> 
>     For parens, if one wanted to highlight them at all,
>     font-lock-bracket-face could be used. Though it's probably better to
>     leave them to the 4th feature level (see js-ts-mode as an example).
>     elixir-ts-mode currently defines 3 levels.
> 
>     For levels, we've currently settled on the scheme that function calls
>     and property lookups go to the 4th level of highlighting, whereas the
>     default is 3. This is all tweakable by the individual user, but I think
>     it's better to stay consistent between the modes.
> 
>     Finally, I see that font-lock-function-name-face ends up being used for
>     parameters (as Andrey mentioned) and local variables as well. That's
>     not
>     great; probably a query that ended up matching too widely. We prefer to
>     use font-lock-variable-name-face (for parameter declarations) or
>     font-lock-variable-use-face for such identifiers. Though it can be hard
>     to reliably distinguish them in a dynamic language, so as far as I'm
>     concerned, they could stay non-highlighted (the uses, that is; the
>     declarations are usually easy to find using queries).
> 
> 
> Thanks for the detailed explanation. It's unfortunate timing, because I 
> published a rework of the faces on MELPA so long and a few people are 
> trying it out. It is a total rework using the faces a bit better.  I can 
> submit the patch later today and start the conversation from there?

I guess I expected that if the mode has been added to the core then the 
development is led here too. And modes maintained externally live more 
easily in ELPA. Anyway, we are where we are.

I see that the latest work 
(https://github.com/wkirschbaum/elixir-ts-mode/pull/36) anticipated at 
least some of my comments.

Remainder:

1) font-lock-variable-name-face is intended for declarations and perhaps 
initial assignments (where it's also an implicit declaration), but for 
other variable references it's better to use 
font-lock-variable-use-face. With my test file, I see examples to the 
contrary, even though some attempt to use the latter face had been made 
(inside the 'elixir-function-call' feature's query).

2) Moving highlighting of function calls and variable (and/or property) 
references to the 4th feature level. Looking at your font-lock rules, it 
seems like the elixir-function-call matches is more targeted than the 
elixir-variable one, but still the other built-in modes put both at 4, 
so it would be good for uniformity. Function definitions (and variable 
definitions/declarations, if they're highlighted separately) can remain 
in the 'declaration' or 'definition' feature which is put in a lower 
feature level (e.g. ruby/js/typescript modes have it on level 1).

Something else I would recommend:

3) Removing the '-face' suffix from the face names. This is the best 
practice across most modes, and it's something the manual entry for 
'defface' recommends:

  You should not quote the symbol face, and it should not end in 
‘-face’ (that would be redundant).

Face names inside font-lock.el are a historical exception (and we 
followed it when adding new faces recently), but if you search for 
'defface' inside the Emacs codebase, such names are in the minority.

I haven't done too much testing myself. Perhaps Andrey will take the 
upstream version for a spin. Or we'll wait for the changes to be merged 
here and continue.

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

From: Andrey Listopadov <andreyorst <at> gmail.com>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>, 67246 <at> debbugs.gnu.org
Subject: Re: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Date: Mon, 20 Nov 2023 13:00:01 +0300 (GMT+03:00)

Nov 20, 2023 04:50:27 Dmitry Gutov <dmitry <at> gutov.dev>:

> I guess I expected that if the mode has been added to the core then the 
> development is led here too. And modes maintained externally live more 
> easily in ELPA. Anyway, we are where we are.

I thought the same thing. I wonder if there are other modes that continue 
development on melpa first, and what is the proper way to set up the 
override in my init.el. I'll have to look into that, I guess.

> I haven't done too much testing myself. Perhaps Andrey will take the 
> upstream version for a spin. Or we'll wait for the changes to be merged 
> here and continue.

I have pulled the melpa package, and at level 2 the font locking now 
seems to be correct (I grew to expect syntax highlights to highlight 
important parts of the code, so level 2 seems the most appropriate to me 
personally).  Thanks for the changes!  However, I don't know how exactly 
tree sitter mode should be organizedm so I can't give a proper review on 
the changes - if there's a guide or a manual for that, I'd like to read 
it.

I guess when the patch for the core package will arive, someone who knows 
how font-locking is organized should give a proper review.

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

From: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>
To: Andrey Listopadov <andreyorst <at> gmail.com>
Cc: 67246 <at> debbugs.gnu.org, Dmitry Gutov <dmitry <at> gutov.dev>
Subject: Re: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Date: Fri, 24 Nov 2023 20:56:41 +0200

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

Sorry for the late response.

On Mon, Nov 20, 2023 at 12:00 PM Andrey Listopadov <andreyorst <at> gmail.com>
wrote:

> Nov 20, 2023 04:50:27 Dmitry Gutov <dmitry <at> gutov.dev>:
>
> > I guess I expected that if the mode has been added to the core then the
> > development is led here too. And modes maintained externally live more
> > easily in ELPA. Anyway, we are where we are.
>

I agree, but not sure how to deal with the users already using it on emacs
29.1 with the MELPA package.
When I wanted to submit the package, I remember there being an email saying
we should not add packages to ELPA yet, so now I am stuck with the github
repository and MELPA.
Once 30 drops it should be easier to redirect conversations here, not sure
how this works.  The packages are slightly different and I regret my
earlier decisions.


>
> I thought the same thing. I wonder if there are other modes that continue
> development on melpa first, and what is the proper way to set up the
> override in my init.el. I'll have to look into that, I guess.
>

There is no need to set an override if you use a conventional method of
loading the package as far as I know.


>
> > I haven't done too much testing myself. Perhaps Andrey will take the
> > upstream version for a spin. Or we'll wait for the changes to be merged
> > here and continue.
>
> I have pulled the melpa package, and at level 2 the font locking now
> seems to be correct (I grew to expect syntax highlights to highlight
> important parts of the code, so level 2 seems the most appropriate to me
> personally).  Thanks for the changes!  However, I don't know how exactly
> tree sitter mode should be organizedm so I can't give a proper review on
> the changes - if there's a guide or a manual for that, I'd like to read
> it.
>

Thanks for checking.  Any feedback will be very helpful, I will prep the
patch in the next day or two.

Wilhelm

[Message part 2 (text/html, inline)]

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

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>,
 Andrey Listopadov <andreyorst <at> gmail.com>
Cc: 67246 <at> debbugs.gnu.org
Subject: Re: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Date: Fri, 24 Nov 2023 21:05:54 +0200

On 24/11/2023 20:56, Wilhelm Kirschbaum wrote:
> On Mon, Nov 20, 2023 at 12:00 PM Andrey Listopadov <andreyorst <at> gmail.com 
> <mailto:andreyorst <at> gmail.com>> wrote:
> 
>     Nov 20, 2023 04:50:27 Dmitry Gutov <dmitry <at> gutov.dev
>     <mailto:dmitry <at> gutov.dev>>:
> 
>      > I guess I expected that if the mode has been added to the core
>     then the
>      > development is led here too. And modes maintained externally live
>     more
>      > easily in ELPA. Anyway, we are where we are.
> 
> 
> I agree, but not sure how to deal with the users already using it on 
> emacs 29.1 with the MELPA package.
> When I wanted to submit the package, I remember there being an email 
> saying we should not add packages to ELPA yet, so now I am stuck with 
> the github repository and MELPA.
> Once 30 drops it should be easier to redirect conversations here, not 
> sure how this works.  The packages are slightly different and I regret 
> my earlier decisions.

OTOH, once Emacs 30 drops, there will be no good way to undo the 
inclusion, if you became so inclined.

Which might be an option currently, since elixir-ts-mode hasn't been in 
an Emacs release yet.

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

From: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: Andrey Listopadov <andreyorst <at> gmail.com>, 67246 <at> debbugs.gnu.org
Subject: Re: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Date: Fri, 24 Nov 2023 21:23:19 +0200

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

On Fri, Nov 24, 2023 at 9:06 PM Dmitry Gutov <dmitry <at> gutov.dev> wrote:

> On 24/11/2023 20:56, Wilhelm Kirschbaum wrote:
> > On Mon, Nov 20, 2023 at 12:00 PM Andrey Listopadov <andreyorst <at> gmail.com
> > <mailto:andreyorst <at> gmail.com>> wrote:
> >
> >     Nov 20, 2023 04:50:27 Dmitry Gutov <dmitry <at> gutov.dev
> >     <mailto:dmitry <at> gutov.dev>>:
> >
> >      > I guess I expected that if the mode has been added to the core
> >     then the
> >      > development is led here too. And modes maintained externally live
> >     more
> >      > easily in ELPA. Anyway, we are where we are.
> >
> >
> > I agree, but not sure how to deal with the users already using it on
> > emacs 29.1 with the MELPA package.
> > When I wanted to submit the package, I remember there being an email
> > saying we should not add packages to ELPA yet, so now I am stuck with
> > the github repository and MELPA.
> > Once 30 drops it should be easier to redirect conversations here, not
> > sure how this works.  The packages are slightly different and I regret
> > my earlier decisions.
>
> OTOH, once Emacs 30 drops, there will be no good way to undo the
> inclusion, if you became so inclined.
>

> Which might be an option currently, since elixir-ts-mode hasn't been in
> an Emacs release yet.
>

I am not sure what you mean? Which option? I meant I regret pushing it to
MELPA first.

[Message part 2 (text/html, inline)]

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

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>
Cc: Andrey Listopadov <andreyorst <at> gmail.com>, 67246 <at> debbugs.gnu.org
Subject: Re: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Date: Fri, 24 Nov 2023 21:30:16 +0200

On 24/11/2023 21:23, Wilhelm Kirschbaum wrote:
> 
> On Fri, Nov 24, 2023 at 9:06 PM Dmitry Gutov <dmitry <at> gutov.dev 
> <mailto:dmitry <at> gutov.dev>> wrote:
> 
>     On 24/11/2023 20:56, Wilhelm Kirschbaum wrote:
>      > On Mon, Nov 20, 2023 at 12:00 PM Andrey Listopadov
>     <andreyorst <at> gmail.com <mailto:andreyorst <at> gmail.com>
>      > <mailto:andreyorst <at> gmail.com <mailto:andreyorst <at> gmail.com>>> wrote:
>      >
>      >     Nov 20, 2023 04:50:27 Dmitry Gutov <dmitry <at> gutov.dev
>     <mailto:dmitry <at> gutov.dev>
>      >     <mailto:dmitry <at> gutov.dev <mailto:dmitry <at> gutov.dev>>>:
>      >
>      >      > I guess I expected that if the mode has been added to the core
>      >     then the
>      >      > development is led here too. And modes maintained
>     externally live
>      >     more
>      >      > easily in ELPA. Anyway, we are where we are.
>      >
>      >
>      > I agree, but not sure how to deal with the users already using it on
>      > emacs 29.1 with the MELPA package.
>      > When I wanted to submit the package, I remember there being an email
>      > saying we should not add packages to ELPA yet, so now I am stuck
>     with
>      > the github repository and MELPA.
>      > Once 30 drops it should be easier to redirect conversations here,
>     not
>      > sure how this works.  The packages are slightly different and I
>     regret
>      > my earlier decisions.
> 
>     OTOH, once Emacs 30 drops, there will be no good way to undo the
>     inclusion, if you became so inclined.
> 
> 
>     Which might be an option currently, since elixir-ts-mode hasn't been in
>     an Emacs release yet.
> 
> 
> I am not sure what you mean? Which option? I meant I regret pushing it 
> to MELPA first.

Ah. If you want it to stay in Emacs core (and not in ELPA), then it 
should be easy enough to pull it from MELPA at any later point. Simply 
asking should suffice.

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

From: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: Andrey Listopadov <andreyorst <at> gmail.com>, 67246 <at> debbugs.gnu.org
Subject: Re: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Date: Fri, 24 Nov 2023 21:47:32 +0200

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

On Mon, Nov 20, 2023 at 3:50 AM Dmitry Gutov <dmitry <at> gutov.dev> wrote:

> On 18/11/2023 09:50, Wilhelm Kirschbaum wrote:
> >
> > On Sat, Nov 18, 2023 at 3:36 AM Dmitry Gutov <dmitry <at> gutov.dev
> > <mailto:dmitry <at> gutov.dev>> wrote:
> >
> >     On 17/11/2023 21:50, Andrey Listopadov wrote:
> >      >
> >      > I've upgraded from elixir-mode to elixir-ts-mode and noticed that
> the
> >      > latter uses faces rather inconsistently.
> >      >
> >      > For example, the =font-lock-keyword-face= is used for both
> >     keywords and
> >      > method calls, as well as for parentheses.  The
> >      > =font-lock-function-name-face= is used both for function
> definitions,
> >      > parameter names, and calls.  Some calls use the
> >      > =font-lock-keyword-face=, for example the call to `raise'.  The
> >      > =font-lock-type-face= is used both for types and =:symbols=.
> >      >
> >      > All of that basically makes Elixir code mostly use 2 colors.
> >      > Additionally, it makes impossible selectively disabling
> >     highlighting, as
> >      > disabling the function call highlighting will disable the function
> >      > definition highlighitng an so on.
> >      >
> >      > I believe, Emacs 29 introduced a lot of faces for all kinds of
> >      > situations possible in Tree-sitter generated AST, so perhaps the
> >     fix is
> >      > to use them more semantically, rather than for good looks.
> >
> >     Thanks for the report. Wilhelm, could you look into this? If you
> >     have time.
> >
> >     Speaking of new faces, we added font-lock-function-call-face that
> >     can be
> >     used for function calls, while font-lock-function-name-face stays
> used
> >     on definitions.
> >
> >     For parens, if one wanted to highlight them at all,
> >     font-lock-bracket-face could be used. Though it's probably better to
> >     leave them to the 4th feature level (see js-ts-mode as an example).
> >     elixir-ts-mode currently defines 3 levels.
> >
> >     For levels, we've currently settled on the scheme that function calls
> >     and property lookups go to the 4th level of highlighting, whereas the
> >     default is 3. This is all tweakable by the individual user, but I
> think
> >     it's better to stay consistent between the modes.
> >
> >     Finally, I see that font-lock-function-name-face ends up being used
> for
> >     parameters (as Andrey mentioned) and local variables as well. That's
> >     not
> >     great; probably a query that ended up matching too widely. We prefer
> to
> >     use font-lock-variable-name-face (for parameter declarations) or
> >     font-lock-variable-use-face for such identifiers. Though it can be
> hard
> >     to reliably distinguish them in a dynamic language, so as far as I'm
> >     concerned, they could stay non-highlighted (the uses, that is; the
> >     declarations are usually easy to find using queries).
> >
> >
> > Thanks for the detailed explanation. It's unfortunate timing, because I
> > published a rework of the faces on MELPA so long and a few people are
> > trying it out. It is a total rework using the faces a bit better.  I can
> > submit the patch later today and start the conversation from there?
>
> I guess I expected that if the mode has been added to the core then the
> development is led here too. And modes maintained externally live more
> easily in ELPA. Anyway, we are where we are.
>
> I see that the latest work
> (https://github.com/wkirschbaum/elixir-ts-mode/pull/36) anticipated at
> least some of my comments.
>
> Remainder:
>
> 1) font-lock-variable-name-face is intended for declarations and perhaps
> initial assignments (where it's also an implicit declaration), but for
> other variable references it's better to use
> font-lock-variable-use-face. With my test file, I see examples to the
> contrary, even though some attempt to use the latter face had been made
> (inside the 'elixir-function-call' feature's query).
>

Thanks, this has been fixed.


>
> 2) Moving highlighting of function calls and variable (and/or property)
> references to the 4th feature level. Looking at your font-lock rules, it
> seems like the elixir-function-call matches is more targeted than the
> elixir-variable one, but still the other built-in modes put both at 4,
> so it would be good for uniformity. Function definitions (and variable
> definitions/declarations, if they're highlighted separately) can remain
> in the 'declaration' or 'definition' feature which is put in a lower
> feature level (e.g. ruby/js/typescript modes have it on level 1).
>

Level 4 is strange to me, because the default is 3.  I read the docs and
tried to
follow it with the new changes, but was hesitant to remove much from the
highlighting as not many people might discover there is a 4th level.  Then
again, if there is a query it
is pretty easy just to communicate this.


>
> Something else I would recommend:
>
> 3) Removing the '-face' suffix from the face names. This is the best
> practice across most modes, and it's something the manual entry for
> 'defface' recommends:
>
>    You should not quote the symbol face, and it should not end in
> ‘-face’ (that would be redundant).
>
> Face names inside font-lock.el are a historical exception (and we
> followed it when adding new faces recently), but if you search for
> 'defface' inside the Emacs codebase, such names are in the minority.
>

Okay thanks, I had a look and it makes sense.  I see a new mode with the
same -face suffixes.
The defface docs does not mention this, so might be a good idea to add it
there?
I am not entirely sure what "you should not quote the symbol face" means
wrt to the changes, because
it does not look like I am quoting it.


>
> I haven't done too much testing myself. Perhaps Andrey will take the
> upstream version for a spin. Or we'll wait for the changes to be merged
> here and continue.
>

[Message part 2 (text/html, inline)]

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

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>
Cc: Andrey Listopadov <andreyorst <at> gmail.com>, 67246 <at> debbugs.gnu.org
Subject: Re: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Date: Sat, 25 Nov 2023 02:21:42 +0200

On 24/11/2023 21:47, Wilhelm Kirschbaum wrote:

>     I see that the latest work
>     (https://github.com/wkirschbaum/elixir-ts-mode/pull/36
>     <https://github.com/wkirschbaum/elixir-ts-mode/pull/36>) anticipated at
>     least some of my comments.
> 
>     Remainder:
> 
>     1) font-lock-variable-name-face is intended for declarations and
>     perhaps
>     initial assignments (where it's also an implicit declaration), but for
>     other variable references it's better to use
>     font-lock-variable-use-face. With my test file, I see examples to the
>     contrary, even though some attempt to use the latter face had been made
>     (inside the 'elixir-function-call' feature's query).
> 
> 
> Thanks, this has been fixed.

Sorry, is there a specific commit in the upstream repo I could look at?

>     2) Moving highlighting of function calls and variable (and/or property)
>     references to the 4th feature level. Looking at your font-lock
>     rules, it
>     seems like the elixir-function-call matches is more targeted than the
>     elixir-variable one, but still the other built-in modes put both at 4,
>     so it would be good for uniformity. Function definitions (and variable
>     definitions/declarations, if they're highlighted separately) can remain
>     in the 'declaration' or 'definition' feature which is put in a lower
>     feature level (e.g. ruby/js/typescript modes have it on level 1).
> 
> 
> Level 4 is strange to me, because the default is 3.  I read the docs and 
> tried to
> follow it with the new changes, but was hesitant to remove much from the
> highlighting as not many people might discover there is a 4th level.  
> Then again, if there is a query it
> is pretty easy just to communicate this.

The idea was to balance the new look between the "old" major modes and 
the newer, shinier ones. So that the overall style still somewhat 
appeals to the existing audience, just with added features and more 
precision. Here's a Reddit recent thread about the same sentiment: 
https://www.reddit.com/r/emacs/comments/18152qo/overcolorization_everything_is_purple/ 
It discusses a post written by Andrey, BTW.

One could basically say that a function call and a properly lookup are 
easy to distinguish from glancing at the text, there's not much need to 
highlight them. As opposed to e.g. implicit variable declaration or 
function declaration.

And here's another aspect: the default built-in theme doesn't 
distinguish many of the faces (and the same is true for many other 
built-in themes). E.g. it doesn't distinguish variable-name-face from 
variable-use-face or function-name-face from function-call-face.

So if the -use- and -call- are used freely, in the default setup they 
will get muddled with the function and variable declaration.

OTOH, if the user installs a theme which has this more advanced support 
for the new faces (or customize the faces manually to be distinct), they 
might as well set treesit-font-lock-level to 4, that's very little extra 
effort.

>     Something else I would recommend:
> 
>     3) Removing the '-face' suffix from the face names. This is the best
>     practice across most modes, and it's something the manual entry for
>     'defface' recommends:
> 
>         You should not quote the symbol face, and it should not end in
>     ‘-face’ (that would be redundant).
> 
>     Face names inside font-lock.el are a historical exception (and we
>     followed it when adding new faces recently), but if you search for
>     'defface' inside the Emacs codebase, such names are in the minority.
> 
> 
> Okay thanks, I had a look and it makes sense.  I see a new mode with the 
> same -face suffixes.
> The defface docs does not mention this, so might be a good idea to add 
> it there?

Probably. I rarely read the manual myself, and this is useful information.

> I am not entirely sure what "you should not quote the symbol face" means 
> wrt to the changes, because
> it does not look like I am quoting it.

Indeed you're not, I only put that in the quote so that the sentence is 
not cut off from the beginning. Sorry if that was confusing.

>     I haven't done too much testing myself. Perhaps Andrey will take the
>     upstream version for a spin. Or we'll wait for the changes to be merged
>     here and continue.
> 

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

From: Andrey Listopadov <andreyorst <at> gmail.com>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>, 67246 <at> debbugs.gnu.org
Subject: Re: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Date: Sat, 25 Nov 2023 11:33:38 +0300

Dmitry Gutov <dmitry <at> gutov.dev> writes:

> The idea was to balance the new look between the "old" major modes and
> the newer, shinier ones. So that the overall style still somewhat
> appeals to the existing audience, just with added features and more
> precision. Here's a Reddit recent thread about the same sentiment:
> https://www.reddit.com/r/emacs/comments/18152qo/overcolorization_everything_is_purple/
> It discusses a post written by Andrey, BTW.

Yes, I published this post after submitting the bug in order to raise
awareness among the community.

> One could basically say that a function call and a properly lookup are
> easy to distinguish from glancing at the text, there's not much need
> to highlight them. As opposed to e.g. implicit variable declaration or
> function declaration.

Yeah, as I said in my post, highlighting important parts of the code,
like macro calls, or dynamic/global variables tells you that you're
looking at something more intricate, that is otherwise syntactically
indistinguishable from regular code.

> And here's another aspect: the default built-in theme doesn't
> distinguish many of the faces (and the same is true for many other
> built-in themes). E.g. it doesn't distinguish variable-name-face from
> variable-use-face or function-name-face from function-call-face.

I'm wondering if font-lock.el needs a bit more generic faces, as
packages often define their own faces, that aren't supported by themes
in any way.  Again, the example with elixir-mode isn't to bash the
developers, but before 2019 elixir-mode (not elixir-ts-mode) defined a
few faces with explicit colors.  Here's a commit that fixed that
https://github.com/elixir-editors/emacs-elixir/commit/f101c676cc9485aa22ec088a71d8afc72cda3d58
but before it, `elixir-atom-face' and `elixir-attribute-face' were
`RoyalBlue4' and `MediumPurple4' no matter what theme you were using.
IIRC the CIDER package also defines some faces like that, so it's
somewhat common.

I can't come up with missing faces, and most modes I use define extra
faces in terms of inheritance to the inbuilt faces, but maybe
font-lock-symbol-face is worth including, as some languages may want to
distinguish these like elixir does right now with `elixir-ts-atom-face'.

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

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Andrey Listopadov <andreyorst <at> gmail.com>
Cc: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>, 67246 <at> debbugs.gnu.org
Subject: Re: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Date: Sun, 26 Nov 2023 01:26:21 +0200

On 25/11/2023 10:33, Andrey Listopadov wrote:

>> And here's another aspect: the default built-in theme doesn't
>> distinguish many of the faces (and the same is true for many other
>> built-in themes). E.g. it doesn't distinguish variable-name-face from
>> variable-use-face or function-name-face from function-call-face.
> 
> I'm wondering if font-lock.el needs a bit more generic faces, as
> packages often define their own faces, that aren't supported by themes
> in any way.  Again, the example with elixir-mode isn't to bash the
> developers, but before 2019 elixir-mode (not elixir-ts-mode) defined a
> few faces with explicit colors.  Here's a commit that fixed that
> https://github.com/elixir-editors/emacs-elixir/commit/f101c676cc9485aa22ec088a71d8afc72cda3d58
> but before it, `elixir-atom-face' and `elixir-attribute-face' were
> `RoyalBlue4' and `MediumPurple4' no matter what theme you were using.
> IIRC the CIDER package also defines some faces like that, so it's
> somewhat common.

As long as the faces are for unusual contexts and have some fallbacks 
(or preferably inherit from some of the core ones), that's fair practice.

> I can't come up with missing faces, and most modes I use define extra
> faces in terms of inheritance to the inbuilt faces,

Right.

> but maybe
> font-lock-symbol-face is worth including, as some languages may want to
> distinguish these like elixir does right now with `elixir-ts-atom-face'.

I agree we could add more. E.g. a face like that could automatically be 
used for "keywords" in Elisp (and Clojure, and other Lisps) and 
"symbols" in Elixir in Ruby.

What makes me pause is naming: the terminology is a mess here across 
languages. "symbols" usually mean something else in Emacs (and in Lisp 
languages in general), whereas "keywords" mean something else across 
most other languages. Using the name font-lock-symbol-face is bound to 
cause confusion at least across Lisp programmers. Luckily, 
'font-lock-keyword-face' is already taken, so we don't have to consider 
this alternative (which would puzzle the rest of the programming world).

The docstring of 'font-lock-constant-face' says "Face name to use for 
constant and label names", but a name 'font-lock-label-name' sounds 
pretty bland... OTOH, there are labels in C, but nothing with that 
particular name in Elixir, Ruby or Lisp (aside from one macro, I suppose).

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

From: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: Andrey Listopadov <andreyorst <at> gmail.com>, 67246 <at> debbugs.gnu.org
Subject: Re: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Date: Mon, 27 Nov 2023 19:59:37 +0200

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

Dmitry Gutov <dmitry <at> gutov.dev> writes:

> On 25/11/2023 10:33, Andrey Listopadov wrote:
>
>>> And here's another aspect: the default built-in theme doesn't
>>> distinguish many of the faces (and the same is true for many 
>>> other
>>> built-in themes). E.g. it doesn't distinguish 
>>> variable-name-face from
>>> variable-use-face or function-name-face from 
>>> function-call-face.
>> I'm wondering if font-lock.el needs a bit more generic faces, 
>> as
>> packages often define their own faces, that aren't supported by 
>> themes
>> in any way.  Again, the example with elixir-mode isn't to bash 
>> the
>> developers, but before 2019 elixir-mode (not elixir-ts-mode) 
>> defined a
>> few faces with explicit colors.  Here's a commit that fixed 
>> that
>> https://github.com/elixir-editors/emacs-elixir/commit/f101c676cc9485aa22ec088a71d8afc72cda3d58
>> but before it, `elixir-atom-face' and `elixir-attribute-face' 
>> were
>> `RoyalBlue4' and `MediumPurple4' no matter what theme you were 
>> using.
>> IIRC the CIDER package also defines some faces like that, so 
>> it's
>> somewhat common.
>
> As long as the faces are for unusual contexts and have some 
> fallbacks
> (or preferably inherit from some of the core ones), that's fair
> practice.
>
>> I can't come up with missing faces, and most modes I use define 
>> extra
>> faces in terms of inheritance to the inbuilt faces,
>
> Right.
>
>> but maybe
>> font-lock-symbol-face is worth including, as some languages may 
>> want to
>> distinguish these like elixir does right now with 
>> `elixir-ts-atom-face'.
>
> I agree we could add more. E.g. a face like that could 
> automatically
> be used for "keywords" in Elisp (and Clojure, and other Lisps) 
> and
> "symbols" in Elixir in Ruby.
>
> What makes me pause is naming: the terminology is a mess here 
> across
> languages. "symbols" usually mean something else in Emacs (and 
> in Lisp
> languages in general), whereas "keywords" mean something else 
> across
> most other languages. Using the name font-lock-symbol-face is 
> bound to
> cause confusion at least across Lisp programmers. Luckily,
> 'font-lock-keyword-face' is already taken, so we don't have to
> consider this alternative (which would puzzle the rest of the
> programming world).
>
> The docstring of 'font-lock-constant-face' says "Face name to 
> use for
> constant and label names", but a name 'font-lock-label-name' 
> sounds
> pretty bland... OTOH, there are labels in C, but nothing with 
> that
> particular name in Elixir, Ruby or Lisp (aside from one macro, I
> suppose).


Here is a patch to address numerous issues flagged on Elixir 
slack,
Github and in this thread.  It will not be perfect, but since the
changes are pretty large I want to get this in and then we can 
pick on
specific issues afterwards if that makes sense?

I am making the assumption that it is okay to rename custom faces 
as
elixir-ts-mode is only for 30.

One thing I tried to get right is to ensure that each level works
relatively well, which means a bit more brute forcing queries.  I 
have
not seen a major performance issue on massic Elixir files, so 
think its
fine.

[0001-Various-improvements-to-font-lock-settings-for-elixi.patch (text/x-patch, attachment)]

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

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>
Cc: Andrey Listopadov <andreyorst <at> gmail.com>, 67246 <at> debbugs.gnu.org
Subject: Re: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Date: Wed, 29 Nov 2023 05:24:53 +0200

On 27/11/2023 19:59, Wilhelm Kirschbaum wrote:
> Here is a patch to address numerous issues flagged on Elixir slack,
> Github and in this thread.  It will not be perfect, but since the
> changes are pretty large I want to get this in and then we can pick on
> specific issues afterwards if that makes sense?

Thank you. No problem, pushed to master.

> I am making the assumption that it is okay to rename custom faces as
> elixir-ts-mode is only for 30.

I think so.

> One thing I tried to get right is to ensure that each level works
> relatively well, which means a bit more brute forcing queries.  I have
> not seen a major performance issue on massic Elixir files, so think its
> fine.

One thing that jumped out at me is that arguments in method definitions 
(e.g. 'def build(parent, root_path, opts) do') are highlighted with the 
-use- face. Apparently, that's simply because the grammar parses these 
as nodes of type "call", just like it does for regular function calls. 
So that's unusual.

I suppose it's possible to separate them by matching on the call 
target's text? Which would be "def" or "defp".

Conversely, variable refs in expressions such as

  %{
    "start" => %{"line" => line, "character" => start_idx},
    "end" => %{"line" => line, "character" => start_idx + length}
  }

are highlighted with -name-, even though there's no destructuring here.

Anyway, good job, I can see that Elixir's grammar is one of the harder 
ones to work with.

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

From: Andrey Listopadov <andreyorst <at> gmail.com>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>, 67246 <at> debbugs.gnu.org
Subject: Re: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Date: Sun, 03 Dec 2023 13:41:20 +0300

Dmitry Gutov <dmitry <at> gutov.dev> writes:

> On 27/11/2023 19:59, Wilhelm Kirschbaum wrote:
>> Here is a patch to address numerous issues flagged on Elixir slack,
>> Github and in this thread.  It will not be perfect, but since the
>> changes are pretty large I want to get this in and then we can pick on
>> specific issues afterwards if that makes sense?
>
> Thank you. No problem, pushed to master.

Thanks! The code now seems to be properly highlighted. I've just tested
the update and noticed that putting the `do' keyword on a separate line
breaks indentation. Here's an example:

defmodule Foo
  do # case A
  @moduledoc """
  Test module.
  """

  defp a(x), do: a(x, 0)

  defp a(x, y),
       do: a(x, 0, 0) # case B

  defp a(x, y, z)
do # case C
  x + y + z
end
  end

I have intentionally introduced incorrect indentation before the first
`do' keyword (case A), but the matching `end' keyword was indented
automatically when I called `indent-region' on the whole buffer. The
case B seems to be indented incorrectly, the default formatter would
indent such `do:' by just two spaces after the parent `defp'.

The third case C is similar to case A, except the indentation was
provided by Emacs, meaning, after pressing the RET key before the `do'
keyword, Emacs had put the keyword at the BOL. If there are no `do'
after the closing parenthesis, the automatic indentation is correct.

I'm not sure if these problems were introduced by the changes, or were
present before, and if I should send a separeate bug report for them, as
this isn't strictly related to highlighting, just with the
tree-sitter-based indentation.


--
Andrey Listopadov

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

From: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: Andrey Listopadov <andreyorst <at> gmail.com>, 67246 <at> debbugs.gnu.org
Subject: Re: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Date: Mon, 04 Dec 2023 19:46:37 +0200

Dmitry Gutov <dmitry <at> gutov.dev> writes:

> On 27/11/2023 19:59, Wilhelm Kirschbaum wrote:
>> Here is a patch to address numerous issues flagged on Elixir 
>> slack,
>> Github and in this thread.  It will not be perfect, but since 
>> the
>> changes are pretty large I want to get this in and then we can 
>> pick on
>> specific issues afterwards if that makes sense?
>
> Thank you. No problem, pushed to master.
>

Thanks, I have one or two more change related to this issue 
coming.

>> I am making the assumption that it is okay to rename custom 
>> faces as
>> elixir-ts-mode is only for 30.
>
> I think so.
>
>> One thing I tried to get right is to ensure that each level 
>> works
>> relatively well, which means a bit more brute forcing queries.  
>> I have
>> not seen a major performance issue on massic Elixir files, so 
>> think its
>> fine.
>
> One thing that jumped out at me is that arguments in method
> definitions (e.g. 'def build(parent, root_path, opts) do') are
> highlighted with the -use- face. Apparently, that's simply 
> because the
> grammar parses these as nodes of type "call", just like it does 
> for
> regular function calls. So that's unusual.
>
> I suppose it's possible to separate them by matching on the call
> target's text? Which would be "def" or "defp".
>
> Conversely, variable refs in expressions such as
>
>   %{
>     "start" => %{"line" => line, "character" => start_idx},
>     "end" => %{"line" => line, "character" => start_idx + 
>     length}
>   }
>
> are highlighted with -name-, even though there's no 
> destructuring here.
>
> Anyway, good job, I can see that Elixir's grammar is one of the 
> harder
> ones to work with.

Thanks.  I am pretty busy atm, so will only get time for this in 
about a
week.  There are definitely some issues I spotted as well which 
needs to
be fixed.

Wilhelm

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

From: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>
To: Andrey Listopadov <andreyorst <at> gmail.com>
Cc: 67246 <at> debbugs.gnu.org, Dmitry Gutov <dmitry <at> gutov.dev>
Subject: Re: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Date: Mon, 04 Dec 2023 19:50:06 +0200

Andrey Listopadov <andreyorst <at> gmail.com> writes:

> Dmitry Gutov <dmitry <at> gutov.dev> writes:
>
>> On 27/11/2023 19:59, Wilhelm Kirschbaum wrote:
>>> Here is a patch to address numerous issues flagged on Elixir 
>>> slack,
>>> Github and in this thread.  It will not be perfect, but since 
>>> the
>>> changes are pretty large I want to get this in and then we can 
>>> pick on
>>> specific issues afterwards if that makes sense?
>>
>> Thank you. No problem, pushed to master.
>
> Thanks! The code now seems to be properly highlighted. I've just 
> tested
> the update and noticed that putting the `do' keyword on a 
> separate line
> breaks indentation. Here's an example:
>
> defmodule Foo
>   do # case A
>   @moduledoc """
>   Test module.
>   """
>
>   defp a(x), do: a(x, 0)
>
>   defp a(x, y),
>        do: a(x, 0, 0) # case B
>
>   defp a(x, y, z)
> do # case C
>   x + y + z
> end
>   end
>
> I have intentionally introduced incorrect indentation before the 
> first
> `do' keyword (case A), but the matching `end' keyword was 
> indented
> automatically when I called `indent-region' on the whole buffer. 
> The
> case B seems to be indented incorrectly, the default formatter 
> would
> indent such `do:' by just two spaces after the parent `defp'.
>
> The third case C is similar to case A, except the indentation 
> was
> provided by Emacs, meaning, after pressing the RET key before 
> the `do'
> keyword, Emacs had put the keyword at the BOL. If there are no 
> `do'
> after the closing parenthesis, the automatic indentation is 
> correct.
>
> I'm not sure if these problems were introduced by the changes, 
> or were
> present before, and if I should send a separeate bug report for 
> them, as
> this isn't strictly related to highlighting, just with the
> tree-sitter-based indentation.

The indention should be another issue imo. The changes in this 
thread
would not impact indentation.

Indentation is probably slightly more complicated than 
fontification, but
planning to take some time in a couple of weeks to fix some 
issues.

Wilhelm

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>
Cc: Andrey Listopadov <andreyorst <at> gmail.com>, Dmitry Gutov <dmitry <at> gutov.dev>,
 67246 <at> debbugs.gnu.org
Subject: Re: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Date: Wed, 10 Jan 2024 09:47:59 -0800

Wilhelm Kirschbaum <wkirschbaum <at> gmail.com> writes:

> Thanks, I have one or two more change related to this issue coming.

Any updates here?

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

From: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Andrey Listopadov <andreyorst <at> gmail.com>, Dmitry Gutov <dmitry <at> gutov.dev>,
 67246 <at> debbugs.gnu.org
Subject: Re: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Date: Sat, 13 Jan 2024 10:50:23 +0200

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

On Wed, Jan 10, 2024 at 7:48 PM Stefan Kangas <stefankangas <at> gmail.com>
wrote:

> Wilhelm Kirschbaum <wkirschbaum <at> gmail.com> writes:
>
> > Thanks, I have one or two more change related to this issue coming.
>
> Any updates here?
>

This patch is the last of the fontification patches for now. Once these are
installed I think we can close this. I will work on some indentation
changes later, but don't think they need to be part of this issue.

Wilhelm

[Message part 2 (text/html, inline)]

[0001-Add-access_call-fontification-to-elixir-ts-mode.patch (text/x-patch, attachment)]

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

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>,
 Stefan Kangas <stefankangas <at> gmail.com>
Cc: Andrey Listopadov <andreyorst <at> gmail.com>, 67246 <at> debbugs.gnu.org
Subject: Re: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Date: Mon, 29 Jan 2024 06:08:28 +0200

Hi!

On 13/01/2024 10:50, Wilhelm Kirschbaum wrote:
> + (access_call target: (identifier) @font-lock-variable-name-face) + 
> (access_call "[" key: (identifier) @font-lock-variable-name-face "]"))

This should use font-lock-variable-use-face. And all other "variable 
reference" highlights should use it too.

OTOH, the method parameters are still highlighted with 
font-lock-variable-use-face, which should be font-lock-variable-name-face.

This happens inside the first 'elixir-variable' highlight. Perhaps 
elixir-ts--definition-keywords-re could be used there to disambiguate as 
well.

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

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>,
 Stefan Kangas <stefankangas <at> gmail.com>
Cc: Andrey Listopadov <andreyorst <at> gmail.com>, 67246 <at> debbugs.gnu.org
Subject: Re: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Date: Tue, 30 Jan 2024 03:59:49 +0200

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

On 29/01/2024 06:08, Dmitry Gutov wrote:
> Hi!
> 
> On 13/01/2024 10:50, Wilhelm Kirschbaum wrote:
>> + (access_call target: (identifier) @font-lock-variable-name-face) + 
>> (access_call "[" key: (identifier) @font-lock-variable-name-face "]"))
> 
> This should use font-lock-variable-use-face. And all other "variable 
> reference" highlights should use it too.
> 
> OTOH, the method parameters are still highlighted with 
> font-lock-variable-use-face, which should be font-lock-variable-name-face.
> 
> This happens inside the first 'elixir-variable' highlight. Perhaps 
> elixir-ts--definition-keywords-re could be used there to disambiguate as 
> well.

See this combined patch:

1. Your additions from the last attachment (access target highlighting).
2. All instances of font-lock-variable-name-face swapped for 
font-lock-variable-use-face (since most of those match variable references).
3. Added highlighting for method parameters with 
font-lock-variable-name-face.
4. Feature elixir-function-name renamed to elixir-definition since it 
now touches both function and variable (parameter) definitions.
5. Feature elixir-variable moved to the feature level 4, since that's 
where it is in other built-in ts modes.

Any objections to it?

[elixir-ts-use-vs-name.diff (text/x-patch, attachment)]

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

From: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>
To: Dmitry Gutov <dmitry <at> gutov.dev>, Stefan Kangas <stefankangas <at> gmail.com>
Cc: Andrey Listopadov <andreyorst <at> gmail.com>, 67246 <at> debbugs.gnu.org
Subject: Re: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Date: Mon, 5 Feb 2024 19:05:31 +0200

On 2024/01/30 03:59, Dmitry Gutov wrote:

> On 29/01/2024 06:08, Dmitry Gutov wrote:
>> Hi!
>>
>> On 13/01/2024 10:50, Wilhelm Kirschbaum wrote:
>>> + (access_call target: (identifier) @font-lock-variable-name-face) + 
>>> (access_call "[" key: (identifier) @font-lock-variable-name-face "]"))
>>
>> This should use font-lock-variable-use-face. And all other "variable 
>> reference" highlights should use it too.
>>
>> OTOH, the method parameters are still highlighted with 
>> font-lock-variable-use-face, which should be 
>> font-lock-variable-name-face.
>>
>> This happens inside the first 'elixir-variable' highlight. Perhaps 
>> elixir-ts--definition-keywords-re could be used there to disambiguate 
>> as well.
>
> See this combined patch:
>
> 1. Your additions from the last attachment (access target highlighting).
> 2. All instances of font-lock-variable-name-face swapped for 
> font-lock-variable-use-face (since most of those match variable 
> references).
Thanks, this makes sense.
> 3. Added highlighting for method parameters with 
> font-lock-variable-name-face.
I had a look and think it covers most instances ( some should arguably 
not be highlighted as use-face, but can be debated ).
> 4. Feature elixir-function-name renamed to elixir-definition since it 
> now touches both function and variable (parameter) definitions.
Makes sense
> 5. Feature elixir-variable moved to the feature level 4, since that's 
> where it is in other built-in ts modes.
>
Agreed.
> Any objections to it?
Thanks for the effort and I have no objections.

There are however some more issues I spotted on the function-name and 
function-call matches which I will be looking into.


Wilhelm

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

From: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>
To: Dmitry Gutov <dmitry <at> gutov.dev>, Stefan Kangas <stefankangas <at> gmail.com>
Cc: Andrey Listopadov <andreyorst <at> gmail.com>, 67246 <at> debbugs.gnu.org
Subject: Re: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Date: Mon, 5 Feb 2024 19:34:16 +0200

On 2024/02/05 19:05, Wilhelm Kirschbaum wrote:
> On 2024/01/30 03:59, Dmitry Gutov wrote:
>
>> On 29/01/2024 06:08, Dmitry Gutov wrote:
>>> Hi!
>>>
>>> On 13/01/2024 10:50, Wilhelm Kirschbaum wrote:
>>>> + (access_call target: (identifier) @font-lock-variable-name-face) 
>>>> + (access_call "[" key: (identifier) @font-lock-variable-name-face 
>>>> "]"))
>>>
>>> This should use font-lock-variable-use-face. And all other "variable 
>>> reference" highlights should use it too.
>>>
>>> OTOH, the method parameters are still highlighted with 
>>> font-lock-variable-use-face, which should be 
>>> font-lock-variable-name-face.
>>>
>>> This happens inside the first 'elixir-variable' highlight. Perhaps 
>>> elixir-ts--definition-keywords-re could be used there to 
>>> disambiguate as well.
>>
>> See this combined patch:
>>
>> 1. Your additions from the last attachment (access target highlighting).
>> 2. All instances of font-lock-variable-name-face swapped for 
>> font-lock-variable-use-face (since most of those match variable 
>> references).
> Thanks, this makes sense.
>> 3. Added highlighting for method parameters with 
>> font-lock-variable-name-face.
> I had a look and think it covers most instances ( some should arguably 
> not be highlighted as use-face, but can be debated ).
>> 4. Feature elixir-function-name renamed to elixir-definition since it 
>> now touches both function and variable (parameter) definitions.
> Makes sense
>> 5. Feature elixir-variable moved to the feature level 4, since that's 
>> where it is in other built-in ts modes.
>>
> Agreed.
>> Any objections to it?
> Thanks for the effort and I have no objections.
>
> There are however some more issues I spotted on the function-name and 
> function-call matches which I will be looking into.

Adding this as the first item to :feature 'elixir-definition fixes the 
function-call/name issue:

@@ -360,13 +360,19 @@ elixir-ts--indent-rules
 (defvar elixir-ts--font-lock-settings
   (treesit-font-lock-rules
    :language 'elixir
-   :feature 'elixir-function-name
+   :feature 'elixir-definition
    `((call target: (identifier) @target-identifier
+           (arguments
+            (call target: (identifier) @font-lock-function-name-face
+                  (arguments)))
+           (:match ,elixir-ts--definition-keywords-re @target-identifier))
+     (call target: (identifier) @target-identifier
            (arguments (identifier) @font-lock-function-name-face)

I will be working in Elixir this week and will set different fonts for 
to test it during the week, but don't think it should hold up installing 
the suggested patch so long.

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

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>,
 Stefan Kangas <stefankangas <at> gmail.com>
Cc: Andrey Listopadov <andreyorst <at> gmail.com>, 67246 <at> debbugs.gnu.org
Subject: Re: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Date: Mon, 5 Feb 2024 19:42:34 +0200

On 05/02/2024 19:34, Wilhelm Kirschbaum wrote:
> 
> Adding this as the first item to :feature 'elixir-definition fixes the 
> function-call/name issue:
> 
> @@ -360,13 +360,19 @@ elixir-ts--indent-rules
>   (defvar elixir-ts--font-lock-settings
>     (treesit-font-lock-rules
>      :language 'elixir
> -   :feature 'elixir-function-name
> +   :feature 'elixir-definition
>      `((call target: (identifier) @target-identifier
> +           (arguments
> +            (call target: (identifier) @font-lock-function-name-face
> +                  (arguments)))
> +           (:match ,elixir-ts--definition-keywords-re @target-identifier))
> +     (call target: (identifier) @target-identifier
>              (arguments (identifier) @font-lock-function-name-face)
> 
> I will be working in Elixir this week and will set different fonts for 
> to test it during the week, but don't think it should hold up installing 
> the suggested patch so long.

Thanks!

Could you give an example of problematic highlighting, though? So I can 
keep it mind when installing both changes.

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

From: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>
To: Dmitry Gutov <dmitry <at> gutov.dev>, Stefan Kangas <stefankangas <at> gmail.com>
Cc: Andrey Listopadov <andreyorst <at> gmail.com>, 67246 <at> debbugs.gnu.org
Subject: Re: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Date: Mon, 5 Feb 2024 19:47:02 +0200

On 2024/02/05 19:42, Dmitry Gutov wrote:

> On 05/02/2024 19:34, Wilhelm Kirschbaum wrote:
>>
>> Adding this as the first item to :feature 'elixir-definition fixes 
>> the function-call/name issue:
>>
>> @@ -360,13 +360,19 @@ elixir-ts--indent-rules
>>   (defvar elixir-ts--font-lock-settings
>>     (treesit-font-lock-rules
>>      :language 'elixir
>> -   :feature 'elixir-function-name
>> +   :feature 'elixir-definition
>>      `((call target: (identifier) @target-identifier
>> +           (arguments
>> +            (call target: (identifier) @font-lock-function-name-face
>> +                  (arguments)))
>> +           (:match ,elixir-ts--definition-keywords-re 
>> @target-identifier))
>> +     (call target: (identifier) @target-identifier
>>              (arguments (identifier) @font-lock-function-name-face)
>>
>> I will be working in Elixir this week and will set different fonts 
>> for to test it during the week, but don't think it should hold up 
>> installing the suggested patch so long.
>
> Thanks!
>
> Could you give an example of problematic highlighting, though? So I 
> can keep it mind when installing both changes.
Of course, sorry:

def boo(:one), do: :boo

highlighted boo as function-call-face, not function-name-face. Same with


def foo("boo") do

end


and variants.

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

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>,
 Stefan Kangas <stefankangas <at> gmail.com>
Cc: Andrey Listopadov <andreyorst <at> gmail.com>, 67246 <at> debbugs.gnu.org
Subject: Re: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Date: Mon, 5 Feb 2024 22:51:18 +0200

On 05/02/2024 19:47, Wilhelm Kirschbaum wrote:
>> Could you give an example of problematic highlighting, though? So I 
>> can keep it mind when installing both changes.
> Of course, sorry:
> 
> def boo(:one), do: :boo
> 
> highlighted boo as function-call-face, not function-name-face. Same with
> 
> 
> def foo("boo") do
> 
> end
> 
> 
> and variants.

Thanks! Now I get it.

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

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>,
 Stefan Kangas <stefankangas <at> gmail.com>
Cc: Andrey Listopadov <andreyorst <at> gmail.com>, 67246 <at> debbugs.gnu.org
Subject: Re: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Date: Wed, 7 Feb 2024 04:21:13 +0200

On 05/02/2024 22:51, Dmitry Gutov wrote:
> On 05/02/2024 19:47, Wilhelm Kirschbaum wrote:
>>> Could you give an example of problematic highlighting, though? So I 
>>> can keep it mind when installing both changes.
>> Of course, sorry:
>>
>> def boo(:one), do: :boo
>>
>> highlighted boo as function-call-face, not function-name-face. Same with
>>
>>
>> def foo("boo") do
>>
>> end
>>
>>
>> and variants.
> 
> Thanks! Now I get it.

I've now pushed the two your patches and one of mine.

Not closing the report yet because you said some problem with function 
calls remains, right?

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

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>,
 Stefan Kangas <stefankangas <at> gmail.com>
Cc: Andrey Listopadov <andreyorst <at> gmail.com>, 67246 <at> debbugs.gnu.org
Subject: Re: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Date: Wed, 7 Feb 2024 04:21:47 +0200

On 05/02/2024 19:05, Wilhelm Kirschbaum wrote:
> I had a look and think it covers most instances ( some should arguably 
> not be highlighted as use-face, but can be debated ).

BTW, if you meant variable assignments here, these indeed could be 
discussed.

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

From: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: Andrey Listopadov <andreyorst <at> gmail.com>, 67246 <at> debbugs.gnu.org,
 Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Date: Fri, 23 Feb 2024 17:05:06 +0200

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

> On 05/02/2024 22:51, Dmitry Gutov wrote:
> > On 05/02/2024 19:47, Wilhelm Kirschbaum wrote:
> >>> Could you give an example of problematic highlighting, though? So I
> >>> can keep it mind when installing both changes.
> >> Of course, sorry:
> >>
> >> def boo(:one), do: :boo
> >>
> >> highlighted boo as function-call-face, not function-name-face. Same with
> >>
> >>
> >> def foo("boo") do
> >>
> >> end
> >>
> >>
> >> and variants.
> >
> > Thanks! Now I get it.
>
> I've now pushed the two your patches and one of mine.
>

Thank you

>
> Not closing the report yet because you said some problem with function
> calls remains, right?
>

Yes, one more with function calls and one issue with else blocks, where the
wrong font gets applied. I will attempt a patch next week.

[Message part 2 (text/html, inline)]

Previous Next

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