GNU logs - #67246, boring messages

X-Loop: help-debbugs@HIDDEN
Subject: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Resent-From: Andrey Listopadov <andreyorst@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 17 Nov 2023 19:57:01 +0000
Resent-Message-ID: <handler.67246.B.170025097312438 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: report 67246
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: 67246 <at> debbugs.gnu.org
X-Debbugs-Original-To: bug-gnu-emacs@HIDDEN
Received: via spool by submit <at> debbugs.gnu.org id=B.170025097312438
          (code B ref -1); Fri, 17 Nov 2023 19:57:01 +0000
Received: (at submit) by debbugs.gnu.org; 17 Nov 2023 19:56:13 +0000
Received: from localhost ([127.0.0.1]:47180 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1r44wm-0003EX-Gk
	for submit <at> debbugs.gnu.org; Fri, 17 Nov 2023 14:56:13 -0500
Received: from lists.gnu.org ([2001:470:142::17]:34626)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <andreyorst@HIDDEN>) id 1r44wj-0003EH-9x
 for submit <at> debbugs.gnu.org; Fri, 17 Nov 2023 14:56:11 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10])
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <andreyorst@HIDDEN>)
 id 1r44wd-000115-7o
 for bug-gnu-emacs@HIDDEN; Fri, 17 Nov 2023 14:56:03 -0500
Received: from mail-lj1-x231.google.com ([2a00:1450:4864:20::231])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.90_1) (envelope-from <andreyorst@HIDDEN>)
 id 1r44wa-0004Rd-Un
 for bug-gnu-emacs@HIDDEN; Fri, 17 Nov 2023 14:56:02 -0500
Received: by mail-lj1-x231.google.com with SMTP id
 38308e7fff4ca-2c5056059e0so33311521fa.3
 for <bug-gnu-emacs@HIDDEN>; Fri, 17 Nov 2023 11:56:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1700250959; x=1700855759; darn=gnu.org;
 h=mime-version:message-id:date:subject:to:from:user-agent:from:to:cc
 :subject:date:message-id:reply-to;
 bh=l7zqwFLp5CSz0ssZEkwK4m/b6nDdyZe5D+66jsVoILo=;
 b=kAfN8p/7k//Pd9EXEj6/ctFOofYJi58p8+20y0gFK+1lSLGDEfi6ruxiH5V1iT9tIY
 wWjOz+QCc7r6B3n/hn3y56RhdJl6zJF6kz8Qd8l6a88xrVh0LKjlXfqFA+6xNGyS0pew
 LoKJwAUuCqSwpcWmvjiOGVh6ZVqJ8evNXiBJpaaAuKpSu3rx9hmkRMx+N6n6ttqScH4E
 4NH/6Z/XimwrMg+iDbqhzG5EU4lDOeJR0ZXR4eCdjsRvMJcMjEWb+D2XvK89QnAwjPFq
 nlGxXn27cU2aHZW+Gu/YYdck96RjKgVgUzqvJl8ATdy4dl/aulYFBUFb9PzylKDIZGGm
 craA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1700250959; x=1700855759;
 h=mime-version:message-id:date:subject:to:from:user-agent
 :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=l7zqwFLp5CSz0ssZEkwK4m/b6nDdyZe5D+66jsVoILo=;
 b=Ak6xZ7+pvNVsRX6bbrCVPTtVLoKmW3BA3QeZLvqIWQDaMTjGk3s73AGogeuimPODod
 +EaBAwvZZzJhb9KKr8bofPHJp3MJIm0gqXg432Q+ct7Rqu8LKkts0OFMOLvoR0zyvlPB
 FgNpW3MwoyZuNvoIc70R3XQO56JcC8cZkV+zOLbiyh4Lr9llEGiXJa1VSZWOhGBr660u
 wMnbrkIHtUMERAMVJpPKmFduCnJhdTsAfX9laVeV7eP+i8cVDRwOb59Si6Y4vW3bSInJ
 Gv3EFKD0+FSTrIkktMedTJswUMu+ZRX16otxH2hHK31KpOkVTNPM5QBHApM4/9Xw97xF
 ihQQ==
X-Gm-Message-State: AOJu0YzNcNBNTQZVHQPq4CsI4AFK6znX9k5D6NAlxprjzPxIY7d9eyk0
 BRncar0VwPQhPB1vlrdNjCajQMa7SPW3tA==
X-Google-Smtp-Source: AGHT+IGGFHGjTsQ2Aub17BD7XOaoSEIxyEF8njUA+RzVNRyHQv2l41zyedXNkTQYxqntxwVZ7oY6BA==
X-Received: by 2002:a2e:a0d2:0:b0:2c5:a21:8388 with SMTP id
 f18-20020a2ea0d2000000b002c50a218388mr458197ljm.29.1700250958700; 
 Fri, 17 Nov 2023 11:55:58 -0800 (PST)
Received: from toolbox.smtp.gmail.com (broadband-90-154-71-4.ip.moscow.rt.ru.
 [90.154.71.4]) by smtp.gmail.com with ESMTPSA id
 r7-20020a170906280700b009cc1e8ed7c5sm1102670ejc.133.2023.11.17.11.55.57
 for <bug-gnu-emacs@HIDDEN>
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 17 Nov 2023 11:55:58 -0800 (PST)
User-agent: mu4e 1.8.11; emacs 30.0.50
From: Andrey Listopadov <andreyorst@HIDDEN>
Date: Fri, 17 Nov 2023 22:50:58 +0300
Message-ID: <87y1ewgnn7.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
Received-SPF: pass client-ip=2a00:1450:4864:20::231;
 envelope-from=andreyorst@HIDDEN; helo=mail-lj1-x231.google.com
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
 T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 1.0 (+)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)


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

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Andrey Listopadov <andreyorst@HIDDEN>
Subject: bug#67246: Acknowledgement (30.0.50; elixir-ts-mode uses faces
 inconsistently)
Message-ID: <handler.67246.B.170025097312438.ack <at> debbugs.gnu.org>
References: <87y1ewgnn7.fsf@HIDDEN>
X-Gnu-PR-Message: ack 67246
X-Gnu-PR-Package: emacs
Reply-To: 67246 <at> debbugs.gnu.org
Date: Fri, 17 Nov 2023 19:57:01 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 67246 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
67246: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D67246
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

X-Loop: help-debbugs@HIDDEN
Subject: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Resent-From: Dmitry Gutov <dmitry@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 18 Nov 2023 01:37:02 +0000
Resent-Message-ID: <handler.67246.B67246.170027140214380 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 67246
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Andrey Listopadov <andreyorst@HIDDEN>, 67246 <at> debbugs.gnu.org, Wilhelm H Kirschbaum <wkirschbaum@HIDDEN>
Received: via spool by 67246-submit <at> debbugs.gnu.org id=B67246.170027140214380
          (code B ref 67246); Sat, 18 Nov 2023 01:37:02 +0000
Received: (at 67246) by debbugs.gnu.org; 18 Nov 2023 01:36:42 +0000
Received: from localhost ([127.0.0.1]:47334 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1r4AGH-0003jr-Lh
	for submit <at> debbugs.gnu.org; Fri, 17 Nov 2023 20:36:41 -0500
Received: from wout5-smtp.messagingengine.com ([64.147.123.21]:50785)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <dmitry@HIDDEN>) id 1r4AGE-0003jd-CY
 for 67246 <at> debbugs.gnu.org; Fri, 17 Nov 2023 20:36:40 -0500
Received: from compute2.internal (compute2.nyi.internal [10.202.2.46])
 by mailout.west.internal (Postfix) with ESMTP id 3718D320090D;
 Fri, 17 Nov 2023 20:36:31 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162])
 by compute2.internal (MEProxy); Fri, 17 Nov 2023 20:36:31 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc
 :content-transfer-encoding:content-type:content-type:date:date
 :from:from:in-reply-to:in-reply-to:message-id:mime-version
 :references:reply-to:sender:subject:subject:to:to; s=fm2; t=
 1700271390; x=1700357790; bh=DNx1f2UYiIMnch9k/F9UcoXPdZUrB+Oj+cl
 4u6ICPdw=; b=rtbMOQQ5vu++oA6TYe13Bgwc7nrYGkdIgMicnNylh28mee2iZ3/
 EDbMk6Z4wu5ONFx85x4nx1OkrumloXzLqv3oX0FpXHtUgbpBFk5d2a7Dd+8jr4MW
 osrFIOpdjG3jgwnOYqMEfh+ApFcDQRyPBXRCLNhQbNb3PxWkP9iGyTMpnchjR0jZ
 BrtrLg+01UMLW42wOGoo/UxR3MsmoZYVoTpjzM6TqADDNcM8vW7xFtbkpkeL7DFI
 P7uHoGnO+hZZ3XAfPiDNOnY8w6LQUoGwmBVHXoW2fixVJSANEBvflJSzIZVYYqSq
 9DgzNq3ePQcH9UEikS+v9CqDr8O9YO0zxbQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:content-transfer-encoding:content-type
 :content-type:date:date:feedback-id:feedback-id:from:from
 :in-reply-to:in-reply-to:message-id:mime-version:references
 :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy
 :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1700271390; x=
 1700357790; bh=DNx1f2UYiIMnch9k/F9UcoXPdZUrB+Oj+cl4u6ICPdw=; b=1
 SSOtxtsuOW8pskT8v7GIOBQnB3Ka2sczboyWl76ULbl2iGMYl69skylGReIvRMqZ
 s6uN6eLCpFKCsZhxY6oMDE+AAKBj/WWd344HRxFT3vAztVT7eOSKE46CkeBhgPZP
 4gzYXFIrILwweCEGrU8Q2AwNYJKQJ4Y6ypLoNiaPrCCobussQpZBu0B12/qo1cPN
 fqyYFtasdMxaHkgzlgX0ioGJgBpxPPKS3/dJBQ2gvO7JQ/Ixlch+voboyiJnhYdt
 R1oZkYew4sHdWZ27zVZHxx9eXLZgMOceqmCdQn5BqKEM0tVuUZtbCBPIucwreCvo
 KQjyA8dG6eSTpL4tNmE/w==
X-ME-Sender: <xms:HhVYZd_sd9XqZEXR25luvGlrEwrdBzAqDz3s-K5ZfW_15yEi6cObiw>
 <xme:HhVYZRtRaqpEwToffwOhFlYSLwOxcGXSFZbTmjfH9xlbk-OxpKpuZEI91eSi5bBIM
 GFAKE1ntRXbx21lFPM>
X-ME-Received: <xmr:HhVYZbAiZzpIwH7n5DplT4p9w2HXwyeRPAbsvM61ERTrdd3S8Nq-UfVx3uXQ3zyVRpAXoA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudeguddgfeefucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
 uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
 cujfgurhepkfffgggfuffvfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhmihht
 rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth
 gvrhhnpeeghedthedujeeiteeutddtjeekheejteeukeehffdutdejuedvfeevueeviedu
 udenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh
 hithhrhiesghhuthhovhdruggvvh
X-ME-Proxy: <xmx:HhVYZRdRN2aGl56q6ULISFyTefebtjYbOQw0Pud4wKk9NSN-Wn1Wsw>
 <xmx:HhVYZSP13yfe-2WG1nbslYwBPHf6_2309vHTIBbFEP7_loYTbS60hw>
 <xmx:HhVYZTluwwf-NclCy2Wau7yA0Gwlmnk6qP6RcGzg548CyRTiA9_dtA>
 <xmx:HhVYZU3IKKUgeluO0ut0wXIasvICCaLYHjZ5AjYUDPftZeadOKOjPg>
Feedback-ID: i0e71465a:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri,
 17 Nov 2023 20:36:29 -0500 (EST)
Message-ID: <e54987bb-5d2a-36b2-9ee3-fc4e3832f06c@HIDDEN>
Date: Sat, 18 Nov 2023 03:36:26 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.13.0
Content-Language: en-US
References: <87y1ewgnn7.fsf@HIDDEN>
From: Dmitry Gutov <dmitry@HIDDEN>
In-Reply-To: <87y1ewgnn7.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -2.9 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.9 (---)

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).

X-Loop: help-debbugs@HIDDEN
Subject: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Resent-From: Wilhelm Kirschbaum <wkirschbaum@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 18 Nov 2023 07:52:02 +0000
Resent-Message-ID: <handler.67246.B67246.170029386920199 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 67246
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dmitry@HIDDEN>
Cc: Andrey Listopadov <andreyorst@HIDDEN>, 67246 <at> debbugs.gnu.org
Received: via spool by 67246-submit <at> debbugs.gnu.org id=B67246.170029386920199
          (code B ref 67246); Sat, 18 Nov 2023 07:52:02 +0000
Received: (at 67246) by debbugs.gnu.org; 18 Nov 2023 07:51:09 +0000
Received: from localhost ([127.0.0.1]:47724 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1r4G6f-0005Fj-3Y
	for submit <at> debbugs.gnu.org; Sat, 18 Nov 2023 02:51:09 -0500
Received: from mail-qt1-x82b.google.com ([2607:f8b0:4864:20::82b]:53536)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <wkirschbaum@HIDDEN>) id 1r4G6c-0005FC-CA
 for 67246 <at> debbugs.gnu.org; Sat, 18 Nov 2023 02:51:07 -0500
Received: by mail-qt1-x82b.google.com with SMTP id
 d75a77b69052e-4219f89ee21so15788581cf.3
 for <67246 <at> debbugs.gnu.org>; Fri, 17 Nov 2023 23:51:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1700293860; x=1700898660; darn=debbugs.gnu.org;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=gXfKJUvt2xtRZroc0krKOGG9/O2RAZc1/g/oJD1a9nY=;
 b=Mwx7zjDAVMGyP/trTo5cfcfokUnIOOLQ7c7ZmQWzFuLsOh0pBxZhIhfDKymiR5Q7eG
 dHbBqqgOT0zfNsgpMOBo+FZvtYaBXvnSqNIMYOY9JLTEiiTs9aZ6JSk5Q/nf7S8lBCYI
 lky2snEEb4/F/GVAGink5QEu43ZISx2t+HyfIpSdOoU1q8jQX58rh4KtyzSdK0VBuV47
 tlOroYMTem9OYe29UzP0PW9U6qPybQxzRFJQZ+zViQlEJFHXe7P+BDZfdbJ33hWj8XLa
 1SBDl29NGp7BOhjspQwFPq/qH95vAZ1mdfj0BkVlSLnoEHlKAXKeYcUiMn9p8F4d3Ehc
 G81Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1700293860; x=1700898660;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=gXfKJUvt2xtRZroc0krKOGG9/O2RAZc1/g/oJD1a9nY=;
 b=IBKJft+/ikN4PezAM44btl6ADSXc8oERFDnsStqE0fLuLg88Gm/KHxc/jEs2Sh7miI
 d4sWRyUV++YRQFIiUndJkmhjDtN+NjJiaWPEi6VL+g57mYMUizlOOXpB7SRojNGiOYFT
 Rsa3oUx7y0sIRt+PB7TcRw2FC/e34wnNKv7QNumhfnFzjH9hf5+g4yqYf9zx1jR5Zqlz
 d6gEwXLA+Zzn11GDzC7g9tlWEEo4LBncAf6+FzJzSvvDYk226DJvkHA7M3LdtbC5tRbR
 sEmPncUuBspAkBAaEYQb1QF799JJafu5FAMt+7wXb/wYx7nvBLTJk6xLNHO4Vw9Jvuwa
 vo+Q==
X-Gm-Message-State: AOJu0YyvV5tkRYHzqayeAanWfSzYYU6EigImlCnpK59P5YrnegwXJKwB
 8PnygJtFOSFLWuUnDRQJl2Zd8GkPyQpqM/opTfc=
X-Google-Smtp-Source: AGHT+IEd2R4wRsTpI7yDqT78kvBBn8RlSZmic9Q9/YcvsN4jtXSnt7c+88cHxa9bi7s+l62081FVAL8W4O7l0gGea88=
X-Received: by 2002:ac8:5dd4:0:b0:41c:e92a:c604 with SMTP id
 e20-20020ac85dd4000000b0041ce92ac604mr2333715qtx.59.1700293859836; Fri, 17
 Nov 2023 23:50:59 -0800 (PST)
MIME-Version: 1.0
References: <87y1ewgnn7.fsf@HIDDEN>
 <e54987bb-5d2a-36b2-9ee3-fc4e3832f06c@HIDDEN>
In-Reply-To: <e54987bb-5d2a-36b2-9ee3-fc4e3832f06c@HIDDEN>
From: Wilhelm Kirschbaum <wkirschbaum@HIDDEN>
Date: Sat, 18 Nov 2023 09:50:48 +0200
Message-ID: <CAOS0-34j_6=QYEVokunwM89F_v7xieWjpnkvGf_-yhBa+yj9Yw@HIDDEN>
Content-Type: multipart/alternative; boundary="00000000000087879f060a688381"
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--00000000000087879f060a688381
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Nov 18, 2023 at 3:36=E2=80=AFAM Dmitry Gutov <dmitry@HIDDEN> wro=
te:

> 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 =3Dfont-lock-keyword-face=3D is used for both keywords=
 and
> > method calls, as well as for parentheses.  The
> > =3Dfont-lock-function-name-face=3D is used both for function definition=
s,
> > parameter names, and calls.  Some calls use the
> > =3Dfont-lock-keyword-face=3D, for example the call to `raise'.  The
> > =3Dfont-lock-type-face=3D is used both for types and =3D:symbols=3D.
> >
> > All of that basically makes Elixir code mostly use 2 colors.
> > Additionally, it makes impossible selectively disabling highlighting, a=
s
> > 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 tim=
e.
>
> 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

--00000000000087879f060a688381
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div>On Sat, Nov 18, 2023 at 3:36=E2=
=80=AFAM Dmitry Gutov &lt;<a href=3D"mailto:dmitry@HIDDEN">dmitry@gutov.=
dev</a>&gt; wrote:<div class=3D"gmail_quote"><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex">On 17/11/2023 21:50, Andrey Listopadov wrote:<br>
&gt; <br>
&gt; I&#39;ve upgraded from elixir-mode to elixir-ts-mode and noticed that =
the<br>
&gt; latter uses faces rather inconsistently.<br>
&gt; <br>
&gt; For example, the =3Dfont-lock-keyword-face=3D is used for both keyword=
s and<br>
&gt; method calls, as well as for parentheses.=C2=A0 The<br>
&gt; =3Dfont-lock-function-name-face=3D is used both for function definitio=
ns,<br>
&gt; parameter names, and calls.=C2=A0 Some calls use the<br>
&gt; =3Dfont-lock-keyword-face=3D, for example the call to `raise&#39;.=C2=
=A0 The<br>
&gt; =3Dfont-lock-type-face=3D is used both for types and =3D:symbols=3D.<b=
r>
&gt; <br>
&gt; All of that basically makes Elixir code mostly use 2 colors.<br>
&gt; Additionally, it makes impossible selectively disabling highlighting, =
as<br>
&gt; disabling the function call highlighting will disable the function<br>
&gt; definition highlighitng an so on.<br>
&gt; <br>
&gt; I believe, Emacs 29 introduced a lot of faces for all kinds of<br>
&gt; situations possible in Tree-sitter generated AST, so perhaps the fix i=
s<br>
&gt; to use them more semantically, rather than for good looks.<br>
<br>
Thanks for the report. Wilhelm, could you look into this? If you have time.=
<br>
<br>
Speaking of new faces, we added font-lock-function-call-face that can be <b=
r>
used for function calls, while font-lock-function-name-face stays used <br>
on definitions.<br>
<br>
For parens, if one wanted to highlight them at all, <br>
font-lock-bracket-face could be used. Though it&#39;s probably better to <b=
r>
leave them to the 4th feature level (see js-ts-mode as an example). <br>
elixir-ts-mode currently defines 3 levels.<br>
<br>
For levels, we&#39;ve currently settled on the scheme that function calls <=
br>
and property lookups go to the 4th level of highlighting, whereas the <br>
default is 3. This is all tweakable by the individual user, but I think <br=
>
it&#39;s better to stay consistent between the modes.<br>
<br>
Finally, I see that font-lock-function-name-face ends up being used for <br=
>
parameters (as Andrey mentioned) and local variables as well. That&#39;s no=
t <br>
great; probably a query that ended up matching too widely. We prefer to <br=
>
use font-lock-variable-name-face (for parameter declarations) or <br>
font-lock-variable-use-face for such identifiers. Though it can be hard <br=
>
to reliably distinguish them in a dynamic language, so as far as I&#39;m <b=
r>
concerned, they could stay non-highlighted (the uses, that is; the <br>
declarations are usually easy to find using queries).<br></blockquote><div>=
<br></div><div>Thanks for the detailed explanation. It&#39;s unfortunate ti=
ming, 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=
.=C2=A0 I can submit the patch later today and start the conversation from =
there? <br></div><div><br></div><div>Wilhelm<br></div></div></div>

--00000000000087879f060a688381--

X-Loop: help-debbugs@HIDDEN
Subject: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Resent-From: Dmitry Gutov <dmitry@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 20 Nov 2023 01:51:02 +0000
Resent-Message-ID: <handler.67246.B67246.170044503922979 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 67246
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Wilhelm Kirschbaum <wkirschbaum@HIDDEN>
Cc: Andrey Listopadov <andreyorst@HIDDEN>, 67246 <at> debbugs.gnu.org
Received: via spool by 67246-submit <at> debbugs.gnu.org id=B67246.170044503922979
          (code B ref 67246); Mon, 20 Nov 2023 01:51:02 +0000
Received: (at 67246) by debbugs.gnu.org; 20 Nov 2023 01:50:39 +0000
Received: from localhost ([127.0.0.1]:52299 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1r4tQt-0005yY-5a
	for submit <at> debbugs.gnu.org; Sun, 19 Nov 2023 20:50:39 -0500
Received: from wout5-smtp.messagingengine.com ([64.147.123.21]:50433)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <dmitry@HIDDEN>) id 1r4tQo-0005yB-KU
 for 67246 <at> debbugs.gnu.org; Sun, 19 Nov 2023 20:50:37 -0500
Received: from compute6.internal (compute6.nyi.internal [10.202.2.47])
 by mailout.west.internal (Postfix) with ESMTP id 81D82320097C;
 Sun, 19 Nov 2023 20:50:26 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162])
 by compute6.internal (MEProxy); Sun, 19 Nov 2023 20:50:26 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc
 :cc:content-transfer-encoding:content-type:content-type:date
 :date:from:from:in-reply-to:in-reply-to:message-id:mime-version
 :references:reply-to:sender:subject:subject:to:to; s=fm2; t=
 1700445026; x=1700531426; bh=nwRset3vFCoXIdjxZC0Exh53C+bfgYz25BD
 d/NWqp48=; b=F1fIChMF4sTT7TtVSyoJTwjdRs5BCriFAf4SGrMRfBxVnQAU/UZ
 p1wRadyEsFi/dYcCUtVK3ZIYq3jHM3R9E5xOLBVQUX3ouaKw0e4O2/l+FjT47Oaa
 oRUSCq+CH2ezCZQyboBW9X+urBKIsUh+UDR45SNZrbfW1UQbAT8Hh9ILxA4pWkVk
 KJGqveQhfSqVCT2BU4r2fMTfCMaOcVDm9z3hWMnxLntIPw3UGOTNNLB/lZtLHJt4
 4mniAAulAQ7/sespmZVYEJBjHUF1hkPUYOaySO1Zlt0kI2M9hblO1DeZFQMkKIZa
 M1wmyCHG4/7SW4ENmHi8q4PPTlOegz3uJ/Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:cc:content-transfer-encoding
 :content-type:content-type:date:date:feedback-id:feedback-id
 :from:from:in-reply-to:in-reply-to:message-id:mime-version
 :references:reply-to:sender:subject:subject:to:to:x-me-proxy
 :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=
 1700445026; x=1700531426; bh=nwRset3vFCoXIdjxZC0Exh53C+bfgYz25BD
 d/NWqp48=; b=wTzrqJjZy7LmZCX7lHad4/pcofhYAmJdYLy9OecpU9uGblRVJyn
 fQGVPNhkLqSRgWbVk77KtzS1oXTedIno2Uv4aqFKr/KK7TdmkdLucdYBqewa5/ti
 RsFUZoukEnwnP0vliUSHjEb/7qtYkaIN9qnrWYnA60R40RG48LjOW0T5JFYrX6XH
 QInfa8+mWUeOPNgv4sJ/9wpo0TN7pfMzjP/nbCVXeOMUAutKmXn+H9w3mx2lMNnl
 ZPsjsgkUWQaiozMWh5eV3HmbRd7+IwKs22V/r/Rzv2OWP8kee6FkujytoMHfQVHr
 WFZN+7ZXnXL6u307G25UBwkZ+gczN3sxnrA==
X-ME-Sender: <xms:YbtaZV4oCb2wVQ37wxKddjIR4m2btXqsGepD73XZ_zlnS6RkX1IIdw>
 <xme:YbtaZS7AyLkkYzkkB1prPl0YZ3bVlBw6Bx38P_c5xW4jgZq2RhHVzlMOwleMcgczs
 1t2WpVAuMgUEcRunaQ>
X-ME-Received: <xmr:YbtaZcd_63waAcXB8dFzkuJgM6wZsKQTcTP1vTa26A6YdqIY2oUg9FBhdtB67Ldsg-bsrg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudeghedgfeelucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
 uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
 cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtfeejnecuhfhrohhmpeffmhhi
 thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth
 htvghrnhepueffveeiffeugffgveejvdegteeuhfdugfehleelfeejtdelteethfdtieeg
 vddunecuffhomhgrihhnpehgihhthhhusgdrtghomhenucevlhhushhtvghrufhiiigvpe
 dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumhhithhrhiesghhuthhovhdruggvvh
X-ME-Proxy: <xmx:YbtaZeKdaWcNot5w_pjGhePQlyUzcyrdc6Mnu3t3bQ1ZL7bdvr-itQ>
 <xmx:YbtaZZIJbbBeTnCyOy9l3X0PsdAsl_meTD4n0a7HLS3-M55lxJb7nA>
 <xmx:YbtaZXzbhARHhvwRECZsQtno9mEj4QgSdjnsCzuliQFDBmFFhK-flA>
 <xmx:YrtaZXjDrTikI6-7LhjldIS36aEjhsgq8z7Zc1Yfam8iSmWtVD-JYQ>
Feedback-ID: i0e71465a:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun,
 19 Nov 2023 20:50:24 -0500 (EST)
Message-ID: <c0ca3975-2930-dbcd-ac44-03d511309b8e@HIDDEN>
Date: Mon, 20 Nov 2023 03:50:23 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.13.0
Content-Language: en-US
References: <87y1ewgnn7.fsf@HIDDEN>
 <e54987bb-5d2a-36b2-9ee3-fc4e3832f06c@HIDDEN>
 <CAOS0-34j_6=QYEVokunwM89F_v7xieWjpnkvGf_-yhBa+yj9Yw@HIDDEN>
From: Dmitry Gutov <dmitry@HIDDEN>
In-Reply-To: <CAOS0-34j_6=QYEVokunwM89F_v7xieWjpnkvGf_-yhBa+yj9Yw@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.9 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.9 (---)

On 18/11/2023 09:50, Wilhelm Kirschbaum wrote:
> 
> On Sat, Nov 18, 2023 at 3:36 AM Dmitry Gutov <dmitry@HIDDEN 
> <mailto:dmitry@HIDDEN>> 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.

X-Loop: help-debbugs@HIDDEN
Subject: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Resent-From: Andrey Listopadov <andreyorst@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 20 Nov 2023 10:01:02 +0000
Resent-Message-ID: <handler.67246.B67246.170047441617450 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 67246
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dmitry@HIDDEN>
Cc: Wilhelm Kirschbaum <wkirschbaum@HIDDEN>, 67246 <at> debbugs.gnu.org
Received: via spool by 67246-submit <at> debbugs.gnu.org id=B67246.170047441617450
          (code B ref 67246); Mon, 20 Nov 2023 10:01:02 +0000
Received: (at 67246) by debbugs.gnu.org; 20 Nov 2023 10:00:16 +0000
Received: from localhost ([127.0.0.1]:52487 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1r514h-0004XO-Kw
	for submit <at> debbugs.gnu.org; Mon, 20 Nov 2023 05:00:15 -0500
Received: from mail-ed1-x532.google.com ([2a00:1450:4864:20::532]:52363)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <andreyorst@HIDDEN>) id 1r514e-0004W2-Ss
 for 67246 <at> debbugs.gnu.org; Mon, 20 Nov 2023 05:00:13 -0500
Received: by mail-ed1-x532.google.com with SMTP id
 4fb4d7f45d1cf-5480edd7026so5202493a12.0
 for <67246 <at> debbugs.gnu.org>; Mon, 20 Nov 2023 02:00:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1700474404; x=1701079204; darn=debbugs.gnu.org;
 h=content-transfer-encoding:mime-version:subject:references
 :in-reply-to:message-id:cc:to:from:date:from:to:cc:subject:date
 :message-id:reply-to;
 bh=hpoaZ4zIqEcP1b65vNGGWMlQtvdIWNZtRyWnRkige38=;
 b=RUqPzN/e1JefzVhhTRlNz7uIC8hWlfIp5GkJU/3oyXvZhvc8xkD0dMN1N8QrwedvMF
 dhtmYNVOvs6v6uk3uZvufB1ay6uBZCSJBxyD6eR/O/HzVfmP7pWeY/ufOBI7Ut/6V1P2
 lG1hOUp8QogA11HtBvUpVm6/l/eYB9s3IFkx6bgircmkOHW6XImbrwNwue4Gr4qDykua
 nyeMr2BdGLqv9ZPKUx9lECoirxkLtT/mVER2r6YsBkPmTJAEMpnpRVLruFZeukSP1/OI
 jHNzMGG0BI54IzLXJBfzCZBEr7hSDBAMzeQCFq7QsDvxIs7LS9hRxKjQGky2LQ0JA7nj
 dkjw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1700474404; x=1701079204;
 h=content-transfer-encoding:mime-version:subject:references
 :in-reply-to:message-id:cc:to:from:date:x-gm-message-state:from:to
 :cc:subject:date:message-id:reply-to;
 bh=hpoaZ4zIqEcP1b65vNGGWMlQtvdIWNZtRyWnRkige38=;
 b=lwSHUxvzwfHpJMVLfmuONyWzn6WMOy9EO2g0SHEoChvbq/SYUh3uVshc/CuoKGtq7S
 /2p5ETSLrrNa2oUNJEc0r4Z01ezml7YIP/Xb8hWfjX0TXt03SNlfvVCl9Zil1coWRbft
 M9D0XCFTcpiifNZ9Ez1CItcq1sDNmvxBwz+PfGUoDu8l4ya3oMLuCj+1R4JtnPJKige3
 F+HKCQNHHi9w85I0TrPJo1tkEsX3MEfW1If4DbTxnaCfZpBYmJpc3Q9y7Vao+uz82UbH
 a0Jz/8mN3Q+bYJ1xwyyCNqPAIt5rVD3LBRGBmVU9XOQ83XOHDrG4rk/y1q1xzMU0ogG+
 dXRw==
X-Gm-Message-State: AOJu0Yy6HvHHJIJofaymVIE4SlSQXvCDTHtqoBr0R7J2FWG9wTTQFDnP
 8ufXjzT3DqmQt46pmprTreE=
X-Google-Smtp-Source: AGHT+IHEAyJArw0w9RDquL7S2bEBskfS42+ZKOFnpSTzF/CmXkl75V4FI9oZeeJZdzO130nBv9XceA==
X-Received: by 2002:a17:906:2212:b0:a00:773c:3f09 with SMTP id
 s18-20020a170906221200b00a00773c3f09mr185603ejs.17.1700474403650; 
 Mon, 20 Nov 2023 02:00:03 -0800 (PST)
Received: from [127.0.0.1] ([176.59.43.116]) by smtp.gmail.com with ESMTPSA id
 cd17-20020a170906b35100b009b2ba067b37sm3686181ejb.202.2023.11.20.02.00.02
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 20 Nov 2023 02:00:03 -0800 (PST)
Date: Mon, 20 Nov 2023 13:00:01 +0300 (GMT+03:00)
From: Andrey Listopadov <andreyorst@HIDDEN>
Message-ID: <4f4e3d4c-e162-4007-a9b5-8210ea2f044b@HIDDEN>
In-Reply-To: <c0ca3975-2930-dbcd-ac44-03d511309b8e@HIDDEN>
References: <87y1ewgnn7.fsf@HIDDEN>
 <e54987bb-5d2a-36b2-9ee3-fc4e3832f06c@HIDDEN>
 <CAOS0-34j_6=QYEVokunwM89F_v7xieWjpnkvGf_-yhBa+yj9Yw@HIDDEN>
 <c0ca3975-2930-dbcd-ac44-03d511309b8e@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Correlation-ID: <4f4e3d4c-e162-4007-a9b5-8210ea2f044b@HIDDEN>
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Nov 20, 2023 04:50:27 Dmitry Gutov <dmitry@HIDDEN>:

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

I thought the same thing. I wonder if there are other modes that continue=
=20
development on melpa first, and what is the proper way to set up the=20
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=20
> upstream version for a spin. Or we'll wait for the changes to be merged=
=20
> here and continue.

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

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

X-Loop: help-debbugs@HIDDEN
Subject: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Resent-From: Wilhelm Kirschbaum <wkirschbaum@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 24 Nov 2023 18:58:01 +0000
Resent-Message-ID: <handler.67246.B67246.170085222529529 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 67246
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Andrey Listopadov <andreyorst@HIDDEN>
Cc: 67246 <at> debbugs.gnu.org, Dmitry Gutov <dmitry@HIDDEN>
Received: via spool by 67246-submit <at> debbugs.gnu.org id=B67246.170085222529529
          (code B ref 67246); Fri, 24 Nov 2023 18:58:01 +0000
Received: (at 67246) by debbugs.gnu.org; 24 Nov 2023 18:57:05 +0000
Received: from localhost ([127.0.0.1]:37289 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1r6bMO-0007gC-Rb
	for submit <at> debbugs.gnu.org; Fri, 24 Nov 2023 13:57:05 -0500
Received: from mail-oa1-x35.google.com ([2001:4860:4864:20::35]:49256)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <wkirschbaum@HIDDEN>) id 1r6bMM-0007fa-Po
 for 67246 <at> debbugs.gnu.org; Fri, 24 Nov 2023 13:57:03 -0500
Received: by mail-oa1-x35.google.com with SMTP id
 586e51a60fabf-1ef36a04931so1337625fac.2
 for <67246 <at> debbugs.gnu.org>; Fri, 24 Nov 2023 10:56:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1700852212; x=1701457012; darn=debbugs.gnu.org;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=CIyPNZZhHbrnqroR7MjOJAiTi/cUGN6B2z7KXQdiUXU=;
 b=iuiPDrlNrtqQzKm+bjLGlF4ZwIIimdKD8IvIfHJNz0XbliG5gMpnW3DpNXnehtfz6G
 +sJBvPLVZu9iYmaR5eeIrVVy6PyoMArLUCF76DVC+NkWe7Z2G7lR7+ulWWdsaOQjxkZB
 ehjKPL5T9E5AWYZlrCJ6/6juYC7KWI3FK7EUeHwjB7NeLCxRS470uQccoDWainJNz5z/
 Na2Gnm9ljlT/4dY5TYoHTaQEUOnSIhAYwBc4fpEVMUzMikqZsxemXxy/99CCLXZieOIU
 DYjLH3njrzXkMmgy1Oa4qecJOYp5pfmZjk0y57UC1tXP9vYdGbWir+4DLN6TZM6MmF2p
 upTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1700852212; x=1701457012;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=CIyPNZZhHbrnqroR7MjOJAiTi/cUGN6B2z7KXQdiUXU=;
 b=KFp4lHh0ixuUbS06NPoI14h6k38yQyEp/wikdYHzfkDhgZy9uJxh96WN0oU7rJCmAC
 eKwv6a27rNC3XZPhg+tAa8hodrTbM5XaKLZarcy6RLl27PuEVCe/ll1TxMwDiXDQlxSA
 e3TX1yNuV8/LfooqFQgwRz/t+vmiQHQ3SWde+OX1abfs6hGLNWdU+ii8YfylG32XELNn
 GZqrz99e8XEmKPLpTxsSLy5IVYWY9dBsEpLk9aeowQKI86Ihqsfbr8upWpqxoAtcK8Nc
 KFJPU3Hei1sFFnbgTUyFJ30IWeb2M3GzLKjWF3JSJvGWWLmPH+MsYkZZs9b6wZId7gjG
 CSNA==
X-Gm-Message-State: AOJu0YwhOZnmqBpIf2nbiKxo03yV/3d8Zmvsu86Z+sPaUD0QcGbnr/E8
 cZykZE13rjgzbFKSvucmOXdyXgyBZ9IprHR7SM8=
X-Google-Smtp-Source: AGHT+IENlX7v6Gmc/Gy4H0g/cRtmiFnThRx4l4xmKw0ThJymP/t1BIHdY6obNuUkIAGIIB2UMubK8G7iyF57uNygWoY=
X-Received: by 2002:a05:6870:b10:b0:1eb:4805:30d9 with SMTP id
 lh16-20020a0568700b1000b001eb480530d9mr4676943oab.49.1700852212221; Fri, 24
 Nov 2023 10:56:52 -0800 (PST)
MIME-Version: 1.0
References: <87y1ewgnn7.fsf@HIDDEN>
 <e54987bb-5d2a-36b2-9ee3-fc4e3832f06c@HIDDEN>
 <CAOS0-34j_6=QYEVokunwM89F_v7xieWjpnkvGf_-yhBa+yj9Yw@HIDDEN>
 <c0ca3975-2930-dbcd-ac44-03d511309b8e@HIDDEN>
 <4f4e3d4c-e162-4007-a9b5-8210ea2f044b@HIDDEN>
In-Reply-To: <4f4e3d4c-e162-4007-a9b5-8210ea2f044b@HIDDEN>
From: Wilhelm Kirschbaum <wkirschbaum@HIDDEN>
Date: Fri, 24 Nov 2023 20:56:41 +0200
Message-ID: <CAOS0-359BvdqEWa0iJC3t0EELr=io-Vk8EFkhvKZGu6+HeCkaQ@HIDDEN>
Content-Type: multipart/alternative; boundary="000000000000eccd34060aea8380"
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--000000000000eccd34060aea8380
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Sorry for the late response.

On Mon, Nov 20, 2023 at 12:00=E2=80=AFPM Andrey Listopadov <andreyorst@gmai=
l.com>
wrote:

> Nov 20, 2023 04:50:27 Dmitry Gutov <dmitry@HIDDEN>:
>
> > 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

--000000000000eccd34060aea8380
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Sorry for the late response. <br></div><div dir=3D"lt=
r"><br></div><div dir=3D"ltr">On Mon, Nov 20, 2023 at 12:00=E2=80=AFPM Andr=
ey Listopadov &lt;<a href=3D"mailto:andreyorst@HIDDEN">andreyorst@gmail.=
com</a>&gt; wrote:</div><div class=3D"gmail_quote"><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex">Nov 20, 2023 04:50:27 Dmitry Gutov &lt;<a href=3D=
"mailto:dmitry@HIDDEN" target=3D"_blank">dmitry@HIDDEN</a>&gt;:<br>
<br>
&gt; I guess I expected that if the mode has been added to the core then th=
e <br>
&gt; development is led here too. And modes maintained externally live more=
 <br>
&gt; easily in ELPA. Anyway, we are where we are.<br></blockquote><div><br>=
</div><div><div>I agree, but not sure how to deal with the users already us=
ing it on emacs 29.1 with the MELPA package.=C2=A0=C2=A0</div><div>When
 I wanted to submit the package, I remember there being an email saying=20
we should not add packages to ELPA yet, so now I am stuck with the=20
github repository and MELPA. <br></div><div>Once 30 drops it should be easi=
er to redirect conversations here, not sure how this works.=C2=A0 The packa=
ges are slightly different and I regret my earlier decisions. <br></div></d=
iv><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I thought the same thing. I wonder if there are other modes that continue <=
br>
development on melpa first, and what is the proper way to set up the <br>
override in my init.el. I&#39;ll have to look into that, I guess.<br></bloc=
kquote><div><br></div><div>There is no need to set an override if you use a=
 conventional method of loading the package as far as I know. <br></div><di=
v>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
&gt; I haven&#39;t done too much testing myself. Perhaps Andrey will take t=
he <br>
&gt; upstream version for a spin. Or we&#39;ll wait for the changes to be m=
erged <br>
&gt; here and continue.<br>
<br>
I have pulled the melpa package, and at level 2 the font locking now <br>
seems to be correct (I grew to expect syntax highlights to highlight <br>
important parts of the code, so level 2 seems the most appropriate to me <b=
r>
personally).=C2=A0 Thanks for the changes!=C2=A0 However, I don&#39;t know =
how exactly <br>
tree sitter mode should be organizedm so I can&#39;t give a proper review o=
n <br>
the changes - if there&#39;s a guide or a manual for that, I&#39;d like to =
read <br>
it.<br></blockquote><div><br></div><div>Thanks for checking.=C2=A0 Any feed=
back will be very helpful, I will prep the patch in the next day or two.</d=
iv><div><br></div><div>Wilhelm<br></div></div></div>

--000000000000eccd34060aea8380--

X-Loop: help-debbugs@HIDDEN
Subject: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Resent-From: Dmitry Gutov <dmitry@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 24 Nov 2023 19:07:02 +0000
Resent-Message-ID: <handler.67246.B67246.17008527738084 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 67246
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Wilhelm Kirschbaum <wkirschbaum@HIDDEN>, Andrey Listopadov <andreyorst@HIDDEN>
Cc: 67246 <at> debbugs.gnu.org
Received: via spool by 67246-submit <at> debbugs.gnu.org id=B67246.17008527738084
          (code B ref 67246); Fri, 24 Nov 2023 19:07:02 +0000
Received: (at 67246) by debbugs.gnu.org; 24 Nov 2023 19:06:13 +0000
Received: from localhost ([127.0.0.1]:37304 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1r6bVF-00026K-0Y
	for submit <at> debbugs.gnu.org; Fri, 24 Nov 2023 14:06:13 -0500
Received: from wout1-smtp.messagingengine.com ([64.147.123.24]:35867)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <dmitry@HIDDEN>) id 1r6bVC-000262-Sz
 for 67246 <at> debbugs.gnu.org; Fri, 24 Nov 2023 14:06:12 -0500
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41])
 by mailout.west.internal (Postfix) with ESMTP id 2E3A93200A5A;
 Fri, 24 Nov 2023 14:05:59 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162])
 by compute1.internal (MEProxy); Fri, 24 Nov 2023 14:05:59 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc
 :cc:content-transfer-encoding:content-type:content-type:date
 :date:from:from:in-reply-to:in-reply-to:message-id:mime-version
 :references:reply-to:sender:subject:subject:to:to; s=fm3; t=
 1700852758; x=1700939158; bh=ol5FOW5H2W/vg3TVWVVkazFSkKWWsOn1QYh
 e6DsRseM=; b=mQiWhOMkpH7dE/g41kfnBZ0m8piMyaJUpR3Ia+K7uCeq+GBWyXS
 ommOeASy+E5BTmWl/Ih1MTXskSMWUqgKlPpvpDMIsBuutAL7nNx4AY2JGX1shiND
 dg5AlBM9hnvZwI4Qas8KyCwNvbWjPMbJQi3a8+nuXGjE5vqUwkrSDw0dzS3M2p9x
 BtoqbQZVfshR7DqkOr+1sfVhFO9RKMVL7SyFS/OkQZzoUmV+2I9rUP+CrIfwZbj9
 J8wDYVJb1wqeoIvy1VPEZf/vQbYzwpzBH3K/t2S0hgfk7VRFxeeb9p6uFsAHNhGX
 iebRAkCoy8r1TadMCherYDRl0UFKM0pEEfg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:cc:content-transfer-encoding
 :content-type:content-type:date:date:feedback-id:feedback-id
 :from:from:in-reply-to:in-reply-to:message-id:mime-version
 :references:reply-to:sender:subject:subject:to:to:x-me-proxy
 :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=
 1700852758; x=1700939158; bh=ol5FOW5H2W/vg3TVWVVkazFSkKWWsOn1QYh
 e6DsRseM=; b=jNfQ0d+Q10nnchnYD6HVqpgYiqVpaRXDexcaDxWMllz0kNyQYmk
 rCSpyqKcoAvBSS6DHaYg/99yiP1Jpo7fosaPCsjRiKlSo3s0koDilhtmcfNa7IF9
 27FW9VDPQaVEf+Vt+fzhykZybs0HX14ip1Qch5lALzcELaLy8la/kczkSpYOM87W
 AxCgiosEWup7+drT1okfSSjatrjNAqGWVeqkxpoKKjOg9BjDieLpxusGRsdcgMPO
 ZRIn6yL2KLfmUJMaBa6sRNSi25DYYWghqW+h3dHbpPAbs5ehFVUt9nslsCSWBSvB
 ftCkEXY2bQLtfPEsHLpHOEXcC1VkRNMaavQ==
X-ME-Sender: <xms:FvRgZUqdNmPdykibR0hyu4KFIPTkOKHV0xVhVdKPEbREViQd8gMkaw>
 <xme:FvRgZaqQv8PoVJr6xrXHuyYCRj9VG3vdw_dd0-lqA5R09PWuALXU5su_TRlGF0Ems
 a4fO8C4jKcz7VrQbg0>
X-ME-Received: <xmr:FvRgZZOsoTQ9VaDladqNRK4Pnn9HsKna0IJjq7dECUuCuODHbAKaMwqFaVNYtcfHqHKZsg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudehhedguddvtdcutefuodetggdotefrod
 ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh
 necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd
 enucfjughrpefkffggfgfuvfevfhfhjggtgfesthekredttdefjeenucfhrhhomhepffhm
 ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg
 htthgvrhhnpefhffehleejffegffeugefhkeektdffgfehjedvgeejtedtudehueffgffg
 feejheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe
 gumhhithhrhiesghhuthhovhdruggvvh
X-ME-Proxy: <xmx:FvRgZb74SYABKUFbYIuatGiMSImk5kQB_QrdBC_pGiGJXN0XCj_bag>
 <xmx:FvRgZT5hZWQ3XKMq1Rv0X2nCKTTNnNsgZjNz8tPpelqXiNZAzMx6Tg>
 <xmx:FvRgZbi3lr7zmp3fxUPob3fvge0vc9ulC6O5oafjj9L6DhZW2H1FWQ>
 <xmx:FvRgZdQd1Is2Qht96j1RBqrVyG0svV8F_cVfDgQIxI6XVI2CPPhTRw>
Feedback-ID: i0e71465a:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri,
 24 Nov 2023 14:05:57 -0500 (EST)
Message-ID: <62c76a1f-586a-751c-0565-baa11ca8a2ae@HIDDEN>
Date: Fri, 24 Nov 2023 21:05:54 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.13.0
Content-Language: en-US
References: <87y1ewgnn7.fsf@HIDDEN>
 <e54987bb-5d2a-36b2-9ee3-fc4e3832f06c@HIDDEN>
 <CAOS0-34j_6=QYEVokunwM89F_v7xieWjpnkvGf_-yhBa+yj9Yw@HIDDEN>
 <c0ca3975-2930-dbcd-ac44-03d511309b8e@HIDDEN>
 <4f4e3d4c-e162-4007-a9b5-8210ea2f044b@HIDDEN>
 <CAOS0-359BvdqEWa0iJC3t0EELr=io-Vk8EFkhvKZGu6+HeCkaQ@HIDDEN>
From: Dmitry Gutov <dmitry@HIDDEN>
In-Reply-To: <CAOS0-359BvdqEWa0iJC3t0EELr=io-Vk8EFkhvKZGu6+HeCkaQ@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.9 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.9 (---)

On 24/11/2023 20:56, Wilhelm Kirschbaum wrote:
> On Mon, Nov 20, 2023 at 12:00 PM Andrey Listopadov <andreyorst@HIDDEN 
> <mailto:andreyorst@HIDDEN>> wrote:
> 
>     Nov 20, 2023 04:50:27 Dmitry Gutov <dmitry@HIDDEN
>     <mailto:dmitry@HIDDEN>>:
> 
>      > 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.

X-Loop: help-debbugs@HIDDEN
Subject: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Resent-From: Wilhelm Kirschbaum <wkirschbaum@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 24 Nov 2023 19:24:02 +0000
Resent-Message-ID: <handler.67246.B67246.17008538259910 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 67246
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dmitry@HIDDEN>
Cc: Andrey Listopadov <andreyorst@HIDDEN>, 67246 <at> debbugs.gnu.org
Received: via spool by 67246-submit <at> debbugs.gnu.org id=B67246.17008538259910
          (code B ref 67246); Fri, 24 Nov 2023 19:24:02 +0000
Received: (at 67246) by debbugs.gnu.org; 24 Nov 2023 19:23:45 +0000
Received: from localhost ([127.0.0.1]:37308 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1r6bmC-0002Zl-QQ
	for submit <at> debbugs.gnu.org; Fri, 24 Nov 2023 14:23:45 -0500
Received: from mail-qt1-x835.google.com ([2607:f8b0:4864:20::835]:58864)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <wkirschbaum@HIDDEN>) id 1r6bm9-0002ZR-6o
 for 67246 <at> debbugs.gnu.org; Fri, 24 Nov 2023 14:23:43 -0500
Received: by mail-qt1-x835.google.com with SMTP id
 d75a77b69052e-4239f2204acso3011551cf.1
 for <67246 <at> debbugs.gnu.org>; Fri, 24 Nov 2023 11:23:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1700853811; x=1701458611; darn=debbugs.gnu.org;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=hBBDlnZ9dzJ+jXSru49tlUj+VAfgj18wAaDNgJYHoxc=;
 b=HFQ023Btspf1MINHQVWmhSW5zBxpvPbhA8JpfA34W3aWhihj4R7btBa74gXTCbfCVu
 PoGNPNMXHRQO4+a018KArKpM1o3EzGSSesauCASxj+Mn0SRosY1VdVNYy3XO0SxFc8gV
 jNA+fOR9EA5dM2P4vLl8GeYjPVduWkk+EsLhEtgL3Lvf/bQklEUFS/Ry7wcz0wE8FHmk
 lZi0beRnBjjO9TyyX35/AQAQ9I0khsPUsWzVkgMZ9eVQ6kLO6JFGD9blpEKapR0DVqjg
 28Mu2JMx6uc0LKo55VvzPe5+RB6UfnlyfhQVONgiRj9VcGEJr9COm+FUJMoPBPLLSGcD
 ks3A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1700853811; x=1701458611;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=hBBDlnZ9dzJ+jXSru49tlUj+VAfgj18wAaDNgJYHoxc=;
 b=tZuRZlrcF4jpfEwTyVlPp2rLn5EFL+UL1XsKYQf0lrelz4OYxguchvy6F8pMGgD1ud
 v+WPg4tAUCkEdjpe3pbZpxXdeBO5gYT3OeuVcon+eqFcohrFdphdT1ae2qEGYClavMmc
 kfpT2Lzq1XRuOt4bSU+RVoI3b7Wtzc5mKH839LJAx9D9UVkHS0qAutvu29PaNQIGjx4e
 eRrRCcemCRTvQp1RxnF+8wA3zHcydvDAGh5LNia+IV/J4RWLUM8Nv7Jffvkp+zc321SD
 CBK7JUPfMlCL2oxjNKnOd0i7KrXVTFcLXhbpMdbqDGmP2ID1y91Df99cNGynUqk/t8ol
 2d3g==
X-Gm-Message-State: AOJu0YwyLl7C3McDyn7KkoyS+dQGu9WWk3vqW8erVyPbxOUwIQb7B/9J
 Fdh0aOTKyTs9mE8fbM5mdu1p6RPmfPTHxK85Ypo=
X-Google-Smtp-Source: AGHT+IHjJiRQibyoZT+3QPSwBM4CIZquZaY9G8D6Abm1flMK3FG7nxpcLFFof6mCR5TX3EiP8SRXZWO+WdJ8kYIr7xg=
X-Received: by 2002:a05:622a:2c5:b0:417:f85b:5a5a with SMTP id
 a5-20020a05622a02c500b00417f85b5a5amr5142768qtx.5.1700853810899; Fri, 24 Nov
 2023 11:23:30 -0800 (PST)
MIME-Version: 1.0
References: <87y1ewgnn7.fsf@HIDDEN>
 <e54987bb-5d2a-36b2-9ee3-fc4e3832f06c@HIDDEN>
 <CAOS0-34j_6=QYEVokunwM89F_v7xieWjpnkvGf_-yhBa+yj9Yw@HIDDEN>
 <c0ca3975-2930-dbcd-ac44-03d511309b8e@HIDDEN>
 <4f4e3d4c-e162-4007-a9b5-8210ea2f044b@HIDDEN>
 <CAOS0-359BvdqEWa0iJC3t0EELr=io-Vk8EFkhvKZGu6+HeCkaQ@HIDDEN>
 <62c76a1f-586a-751c-0565-baa11ca8a2ae@HIDDEN>
In-Reply-To: <62c76a1f-586a-751c-0565-baa11ca8a2ae@HIDDEN>
From: Wilhelm Kirschbaum <wkirschbaum@HIDDEN>
Date: Fri, 24 Nov 2023 21:23:19 +0200
Message-ID: <CAOS0-34JrbfFxpfAwzryh7qpcaVTtAcZqtCynia4ovhY8DqsAQ@HIDDEN>
Content-Type: multipart/alternative; boundary="00000000000036af13060aeae340"
X-Spam-Score: 1.0 (+)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--00000000000036af13060aeae340
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Nov 24, 2023 at 9:06=E2=80=AFPM Dmitry Gutov <dmitry@HIDDEN> wro=
te:

> On 24/11/2023 20:56, Wilhelm Kirschbaum wrote:
> > On Mon, Nov 20, 2023 at 12:00=E2=80=AFPM Andrey Listopadov <andreyorst@=
gmail.com
> > <mailto:andreyorst@HIDDEN>> wrote:
> >
> >     Nov 20, 2023 04:50:27 Dmitry Gutov <dmitry@HIDDEN
> >     <mailto:dmitry@HIDDEN>>:
> >
> >      > 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 liv=
e
> >     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.

--00000000000036af13060aeae340
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><div class=3D"gmail_quote"><div=
 dir=3D"ltr" class=3D"gmail_attr">On Fri, Nov 24, 2023 at 9:06=E2=80=AFPM D=
mitry Gutov &lt;<a href=3D"mailto:dmitry@HIDDEN">dmitry@HIDDEN</a>&gt=
; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 24/1=
1/2023 20:56, Wilhelm Kirschbaum wrote:<br>
&gt; On Mon, Nov 20, 2023 at 12:00=E2=80=AFPM Andrey Listopadov &lt;<a href=
=3D"mailto:andreyorst@HIDDEN" target=3D"_blank">andreyorst@HIDDEN</a>=
 <br>
&gt; &lt;mailto:<a href=3D"mailto:andreyorst@HIDDEN" target=3D"_blank">a=
ndreyorst@HIDDEN</a>&gt;&gt; wrote:<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0Nov 20, 2023 04:50:27 Dmitry Gutov &lt;<a href=3D"m=
ailto:dmitry@HIDDEN" target=3D"_blank">dmitry@HIDDEN</a><br>
&gt;=C2=A0 =C2=A0 =C2=A0&lt;mailto:<a href=3D"mailto:dmitry@HIDDEN" targ=
et=3D"_blank">dmitry@HIDDEN</a>&gt;&gt;:<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; I guess I expected that if the mode has been =
added to the core<br>
&gt;=C2=A0 =C2=A0 =C2=A0then the<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; development is led here too. And modes mainta=
ined externally live<br>
&gt;=C2=A0 =C2=A0 =C2=A0more<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; easily in ELPA. Anyway, we are where we are.<=
br>
&gt; <br>
&gt; <br>
&gt; I agree, but not sure how to deal with the users already using it on <=
br>
&gt; emacs 29.1 with the MELPA package.<br>
&gt; When I wanted to submit the package, I remember there being an email <=
br>
&gt; saying we should not add packages to ELPA yet, so now I am stuck with =
<br>
&gt; the github repository and MELPA.<br>
&gt; Once 30 drops it should be easier to redirect conversations here, not =
<br>
&gt; sure how this works.=C2=A0 The packages are slightly different and I r=
egret <br>
&gt; my earlier decisions.<br>
<br>
OTOH, once Emacs 30 drops, there will be no good way to undo the <br>
inclusion, if you became so inclined. <br></blockquote><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex">
<br>
Which might be an option currently, since elixir-ts-mode hasn&#39;t been in=
 <br>
an Emacs release yet.<br></blockquote><div><br></div><div>I am not sure wha=
t you mean? Which option? I meant I regret pushing it to MELPA first. <br><=
/div></div></div>

--00000000000036af13060aeae340--

X-Loop: help-debbugs@HIDDEN
Subject: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Resent-From: Dmitry Gutov <dmitry@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 24 Nov 2023 19:31:02 +0000
Resent-Message-ID: <handler.67246.B67246.170085423410696 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 67246
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Wilhelm Kirschbaum <wkirschbaum@HIDDEN>
Cc: Andrey Listopadov <andreyorst@HIDDEN>, 67246 <at> debbugs.gnu.org
Received: via spool by 67246-submit <at> debbugs.gnu.org id=B67246.170085423410696
          (code B ref 67246); Fri, 24 Nov 2023 19:31:02 +0000
Received: (at 67246) by debbugs.gnu.org; 24 Nov 2023 19:30:34 +0000
Received: from localhost ([127.0.0.1]:37314 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1r6bsn-0002mS-R0
	for submit <at> debbugs.gnu.org; Fri, 24 Nov 2023 14:30:34 -0500
Received: from wout1-smtp.messagingengine.com ([64.147.123.24]:34663)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <dmitry@HIDDEN>) id 1r6bsl-0002mB-4M
 for 67246 <at> debbugs.gnu.org; Fri, 24 Nov 2023 14:30:32 -0500
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41])
 by mailout.west.internal (Postfix) with ESMTP id 3B45A3200A76;
 Fri, 24 Nov 2023 14:30:20 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162])
 by compute1.internal (MEProxy); Fri, 24 Nov 2023 14:30:20 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc
 :cc:content-transfer-encoding:content-type:content-type:date
 :date:from:from:in-reply-to:in-reply-to:message-id:mime-version
 :references:reply-to:sender:subject:subject:to:to; s=fm3; t=
 1700854219; x=1700940619; bh=uHK+dz7f9R4cdAJhZrP6FCJpJ1/5dTbWXZ2
 w0mSemmU=; b=neaG+KFJieYvMydmBouZww1YUO1p6EFzpksz/YgIWIQwswLRAmq
 4xnHiyTpR3BdfSlLX9ToRNlz0CgrVjxGpeTWhSgj7QPcO7y96M0OwKNBDNbY5JTc
 erU+BIIPIJ3teQjw4BYWOAd7cfBRkv9ju6254D+Y1afLM11aYsw0eCcZxA26CE5/
 CYCGW2b2PKqv4L2inQYJ4fpnQ5kDSL2ac8eRNHK0duYkVHZTnPCMwuc/bTWAlHFR
 5iKCV4i2qQEwZYWBV6Folhhxq7hEnAgqyG1JklHhFym65dDa87nSd/wfTucSsETw
 mW8sJPuZYch9QKSgwvqYlzgIhh7z5tKaXDA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:cc:content-transfer-encoding
 :content-type:content-type:date:date:feedback-id:feedback-id
 :from:from:in-reply-to:in-reply-to:message-id:mime-version
 :references:reply-to:sender:subject:subject:to:to:x-me-proxy
 :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=
 1700854219; x=1700940619; bh=uHK+dz7f9R4cdAJhZrP6FCJpJ1/5dTbWXZ2
 w0mSemmU=; b=RMxzlu5ZAp8H8pyDBPsrkvcVym4kcM1F63+Zl2rHBVO+51d/xuB
 OyX43CUA1eeIAcRixWY81OtNM4YiaCcXQwaReCHUQ7g7D9BBm0gQ8vOuWD+xdEJ5
 YGfethauqTFx0FxPeCT+Pzle6Z8Uuz8ukoooxEVwBseiAkeW0ObqN/BC3Foxchay
 M0JO3msvTQczGEleOxhJTaS42WGNgJObpoklLev74l+lE/RreD0y/Kr4g21O49Xi
 lc9MtTsl2O4f09+DdWf+NODAqWZwkDaB9hti9AH1aJscta2kLeDVg53DFqM0Oxd6
 eT8balIe3j/lSstnAjEQDvnJ3BUIfZVCJfg==
X-ME-Sender: <xms:y_lgZeWw8XUMPqj6KpQQKG1hpb-1FVOLS8mPJWTWKeKurC_R0iKzJw>
 <xme:y_lgZakr6E2aa_rsZrVHon3G80kXPKnIYcXrZ9vvxWcVEJZxQ702EvCd7b6E1cONw
 hKYnsLfJJ8czL81KCE>
X-ME-Received: <xmr:y_lgZSbFQIhy1rY3Ksym8W3FtesX0lAvslrX_LlaPTa0p1hECButiV_ViaijWYeQG4FpFA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudehhedguddvhecutefuodetggdotefrod
 ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh
 necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd
 enucfjughrpefkffggfgfuvfevfhfhjggtgfesthekredttdefjeenucfhrhhomhepffhm
 ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg
 htthgvrhhnpefhffehleejffegffeugefhkeektdffgfehjedvgeejtedtudehueffgffg
 feejheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe
 gumhhithhrhiesghhuthhovhdruggvvh
X-ME-Proxy: <xmx:y_lgZVWBnyx2ILZizIjSzYxI53eDai-lmtvXXjjFmuUvAg3O2iDbZA>
 <xmx:y_lgZYkzvHpNULDqr0N2gh3Jxk-4zT55KprSBIPlmWDLZYSZFgMYmA>
 <xmx:y_lgZaejoSkEP_5ZYIj5RmkRlMTcqw2FWIV2HyTQwBzuyfKsS09ZUA>
 <xmx:y_lgZUuCg2k5NBeBQ5uyYHElK-_7KLDXZNs-g9m0EzcMW5lO18oRwg>
Feedback-ID: i0e71465a:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri,
 24 Nov 2023 14:30:18 -0500 (EST)
Message-ID: <cef11c60-03b1-3a67-2f9d-40839eb132be@HIDDEN>
Date: Fri, 24 Nov 2023 21:30:16 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.13.0
Content-Language: en-US
References: <87y1ewgnn7.fsf@HIDDEN>
 <e54987bb-5d2a-36b2-9ee3-fc4e3832f06c@HIDDEN>
 <CAOS0-34j_6=QYEVokunwM89F_v7xieWjpnkvGf_-yhBa+yj9Yw@HIDDEN>
 <c0ca3975-2930-dbcd-ac44-03d511309b8e@HIDDEN>
 <4f4e3d4c-e162-4007-a9b5-8210ea2f044b@HIDDEN>
 <CAOS0-359BvdqEWa0iJC3t0EELr=io-Vk8EFkhvKZGu6+HeCkaQ@HIDDEN>
 <62c76a1f-586a-751c-0565-baa11ca8a2ae@HIDDEN>
 <CAOS0-34JrbfFxpfAwzryh7qpcaVTtAcZqtCynia4ovhY8DqsAQ@HIDDEN>
From: Dmitry Gutov <dmitry@HIDDEN>
In-Reply-To: <CAOS0-34JrbfFxpfAwzryh7qpcaVTtAcZqtCynia4ovhY8DqsAQ@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.9 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.9 (---)

On 24/11/2023 21:23, Wilhelm Kirschbaum wrote:
> 
> On Fri, Nov 24, 2023 at 9:06 PM Dmitry Gutov <dmitry@HIDDEN 
> <mailto:dmitry@HIDDEN>> wrote:
> 
>     On 24/11/2023 20:56, Wilhelm Kirschbaum wrote:
>      > On Mon, Nov 20, 2023 at 12:00 PM Andrey Listopadov
>     <andreyorst@HIDDEN <mailto:andreyorst@HIDDEN>
>      > <mailto:andreyorst@HIDDEN <mailto:andreyorst@HIDDEN>>> wrote:
>      >
>      >     Nov 20, 2023 04:50:27 Dmitry Gutov <dmitry@HIDDEN
>     <mailto:dmitry@HIDDEN>
>      >     <mailto:dmitry@HIDDEN <mailto:dmitry@HIDDEN>>>:
>      >
>      >      > 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.

X-Loop: help-debbugs@HIDDEN
Subject: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Resent-From: Wilhelm Kirschbaum <wkirschbaum@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 24 Nov 2023 19:48:01 +0000
Resent-Message-ID: <handler.67246.B67246.170085528012522 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 67246
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dmitry@HIDDEN>
Cc: Andrey Listopadov <andreyorst@HIDDEN>, 67246 <at> debbugs.gnu.org
Received: via spool by 67246-submit <at> debbugs.gnu.org id=B67246.170085528012522
          (code B ref 67246); Fri, 24 Nov 2023 19:48:01 +0000
Received: (at 67246) by debbugs.gnu.org; 24 Nov 2023 19:48:00 +0000
Received: from localhost ([127.0.0.1]:37318 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1r6c9f-0003Fn-Nb
	for submit <at> debbugs.gnu.org; Fri, 24 Nov 2023 14:48:00 -0500
Received: from mail-qt1-x82f.google.com ([2607:f8b0:4864:20::82f]:44441)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <wkirschbaum@HIDDEN>) id 1r6c9a-0003Ee-3v
 for 67246 <at> debbugs.gnu.org; Fri, 24 Nov 2023 14:47:58 -0500
Received: by mail-qt1-x82f.google.com with SMTP id
 d75a77b69052e-41cd4cc515fso11839291cf.1
 for <67246 <at> debbugs.gnu.org>; Fri, 24 Nov 2023 11:47:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1700855264; x=1701460064; darn=debbugs.gnu.org;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=O+l4IrU5iMU3dqz73/u7FugvVULv8gX04lMRTXL8R4o=;
 b=FrlabXhlPLjuCt1j+BYkNdSTPFGB9q6HwpNivRgzIdNVhHDDs0fx/egMy2RIFfRRh7
 SJZIybLgDvLSjfobaC10WSE7FzVWCQGa/ktFAj4El8R60x8VBuRF/+fnprLuHL5wrHHS
 kZTOhKV7avnLfqUiCvDy4hzy0mJPxIBdLcSfumnhfZDYE7Phu3yLLeIGhCEFdmrGLq0s
 dqLnMeAifzTVOJ3r9Izp/lhJhvrjpL9NtJm86TJA5OXbHnN5m/SxCwufave/YC5mI9W3
 KBVOMkEiwHDpr+dpo0ZzDt1ZZ8lm2IZ5R65P+gXO1jjZXl5iJessksKGh78nhYrvznW5
 F7ug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1700855264; x=1701460064;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=O+l4IrU5iMU3dqz73/u7FugvVULv8gX04lMRTXL8R4o=;
 b=g2e5AtAVNoRvsaxKebVlkFUtwgdgDamFCWMHa3hmL7Cgj7pwk8QAUWIaMrZXkRiGMz
 3uoF1p1f0Vu2pP68qJ7qYZ1Kz6Tkxn4nDVevhzuI4rHN7FbKSDxt+nUMbzJ2q84Zil5s
 /BhitLsMoMIq9/lW1lbSvF11hK/g+mpNouiAhOyx9ZE6No2Ns8hQavZDcQpWqMNeH5+b
 Ha/K/BSE1jh73xge00PMKzhO2u8tkxUr7qwuGfDqCjWQHiSi27YCKnTM3XwZWLviSDnl
 5eOc6OHVtPgQ8KqGqcn6xg6gNHUw+aWV7HXOGspgUMtS0naFGwSeiKjKtFPcK8/2vQU8
 vmAQ==
X-Gm-Message-State: AOJu0Yxil4d9ixeYmtBZsyD+X5mOIMA0qETeHXUMzrxFIvJQ6tzCIAga
 ViIcLJ5Ew50qnevsLaBkiROPVS35cicyC9O5cEQ=
X-Google-Smtp-Source: AGHT+IHYGMlzbQTn0uSlzmla/Qi+5uNr7E+xPlvp+yueiTigMqfCX0JgrmZiTCaJ8zEyJlPF/0HdzX07tfDGACr8ig8=
X-Received: by 2002:a05:622a:a13:b0:423:98be:e73e with SMTP id
 bv19-20020a05622a0a1300b0042398bee73emr4592630qtb.66.1700855263713; Fri, 24
 Nov 2023 11:47:43 -0800 (PST)
MIME-Version: 1.0
References: <87y1ewgnn7.fsf@HIDDEN>
 <e54987bb-5d2a-36b2-9ee3-fc4e3832f06c@HIDDEN>
 <CAOS0-34j_6=QYEVokunwM89F_v7xieWjpnkvGf_-yhBa+yj9Yw@HIDDEN>
 <c0ca3975-2930-dbcd-ac44-03d511309b8e@HIDDEN>
In-Reply-To: <c0ca3975-2930-dbcd-ac44-03d511309b8e@HIDDEN>
From: Wilhelm Kirschbaum <wkirschbaum@HIDDEN>
Date: Fri, 24 Nov 2023 21:47:32 +0200
Message-ID: <CAOS0-34r3DSEWN2cGGQHdvn71z-T1=bV9WCWmd322HxesdwLHQ@HIDDEN>
Content-Type: multipart/alternative; boundary="000000000000cee100060aeb39bc"
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--000000000000cee100060aeb39bc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Nov 20, 2023 at 3:50=E2=80=AFAM Dmitry Gutov <dmitry@HIDDEN> wro=
te:

> On 18/11/2023 09:50, Wilhelm Kirschbaum wrote:
> >
> > On Sat, Nov 18, 2023 at 3:36=E2=80=AFAM Dmitry Gutov <dmitry@HIDDEN
> > <mailto:dmitry@HIDDEN>> wrote:
> >
> >     On 17/11/2023 21:50, Andrey Listopadov wrote:
> >      >
> >      > I've upgraded from elixir-mode to elixir-ts-mode and noticed tha=
t
> the
> >      > latter uses faces rather inconsistently.
> >      >
> >      > For example, the =3Dfont-lock-keyword-face=3D is used for both
> >     keywords and
> >      > method calls, as well as for parentheses.  The
> >      > =3Dfont-lock-function-name-face=3D is used both for function
> definitions,
> >      > parameter names, and calls.  Some calls use the
> >      > =3Dfont-lock-keyword-face=3D, for example the call to `raise'.  =
The
> >      > =3Dfont-lock-type-face=3D is used both for types and =3D:symbols=
=3D.
> >      >
> >      > 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 functi=
on
> >      > 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 t=
o
> >     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 cal=
ls
> >     and property lookups go to the 4th level of highlighting, whereas t=
he
> >     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 prefe=
r
> 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 ca=
n
> > 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
> =E2=80=98-face=E2=80=99 (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.
>

--000000000000cee100060aeb39bc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Mon, Nov 20, 2023 at 3:50=E2=80=AF=
AM Dmitry Gutov &lt;<a href=3D"mailto:dmitry@HIDDEN">dmitry@HIDDEN</a=
>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On =
18/11/2023 09:50, Wilhelm Kirschbaum wrote:<br>
&gt; <br>
&gt; On Sat, Nov 18, 2023 at 3:36=E2=80=AFAM Dmitry Gutov &lt;<a href=3D"ma=
ilto:dmitry@HIDDEN" target=3D"_blank">dmitry@HIDDEN</a> <br>
&gt; &lt;mailto:<a href=3D"mailto:dmitry@HIDDEN" target=3D"_blank">dmitr=
y@HIDDEN</a>&gt;&gt; wrote:<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0On 17/11/2023 21:50, Andrey Listopadov wrote:<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; I&#39;ve upgraded from elixir-mode to elixir-=
ts-mode and noticed that the<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; latter uses faces rather inconsistently.<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; For example, the =3Dfont-lock-keyword-face=3D=
 is used for both<br>
&gt;=C2=A0 =C2=A0 =C2=A0keywords and<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; method calls, as well as for parentheses.=C2=
=A0 The<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; =3Dfont-lock-function-name-face=3D is used bo=
th for function definitions,<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; parameter names, and calls.=C2=A0 Some calls =
use the<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; =3Dfont-lock-keyword-face=3D, for example the=
 call to `raise&#39;.=C2=A0 The<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; =3Dfont-lock-type-face=3D is used both for ty=
pes and =3D:symbols=3D.<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; All of that basically makes Elixir code mostl=
y use 2 colors.<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; Additionally, it makes impossible selectively=
 disabling<br>
&gt;=C2=A0 =C2=A0 =C2=A0highlighting, as<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; disabling the function call highlighting will=
 disable the function<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; definition highlighitng an so on.<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; I believe, Emacs 29 introduced a lot of faces=
 for all kinds of<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; situations possible in Tree-sitter generated =
AST, so perhaps the<br>
&gt;=C2=A0 =C2=A0 =C2=A0fix is<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &gt; to use them more semantically, rather than fo=
r good looks.<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0Thanks for the report. Wilhelm, could you look into=
 this? If you<br>
&gt;=C2=A0 =C2=A0 =C2=A0have time.<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0Speaking of new faces, we added font-lock-function-=
call-face that<br>
&gt;=C2=A0 =C2=A0 =C2=A0can be<br>
&gt;=C2=A0 =C2=A0 =C2=A0used for function calls, while font-lock-function-n=
ame-face stays used<br>
&gt;=C2=A0 =C2=A0 =C2=A0on definitions.<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0For parens, if one wanted to highlight them at all,=
<br>
&gt;=C2=A0 =C2=A0 =C2=A0font-lock-bracket-face could be used. Though it&#39=
;s probably better to<br>
&gt;=C2=A0 =C2=A0 =C2=A0leave them to the 4th feature level (see js-ts-mode=
 as an example).<br>
&gt;=C2=A0 =C2=A0 =C2=A0elixir-ts-mode currently defines 3 levels.<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0For levels, we&#39;ve currently settled on the sche=
me that function calls<br>
&gt;=C2=A0 =C2=A0 =C2=A0and property lookups go to the 4th level of highlig=
hting, whereas the<br>
&gt;=C2=A0 =C2=A0 =C2=A0default is 3. This is all tweakable by the individu=
al user, but I think<br>
&gt;=C2=A0 =C2=A0 =C2=A0it&#39;s better to stay consistent between the mode=
s.<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0Finally, I see that font-lock-function-name-face en=
ds up being used for<br>
&gt;=C2=A0 =C2=A0 =C2=A0parameters (as Andrey mentioned) and local variable=
s as well. That&#39;s<br>
&gt;=C2=A0 =C2=A0 =C2=A0not<br>
&gt;=C2=A0 =C2=A0 =C2=A0great; probably a query that ended up matching too =
widely. We prefer to<br>
&gt;=C2=A0 =C2=A0 =C2=A0use font-lock-variable-name-face (for parameter dec=
larations) or<br>
&gt;=C2=A0 =C2=A0 =C2=A0font-lock-variable-use-face for such identifiers. T=
hough it can be hard<br>
&gt;=C2=A0 =C2=A0 =C2=A0to reliably distinguish them in a dynamic language,=
 so as far as I&#39;m<br>
&gt;=C2=A0 =C2=A0 =C2=A0concerned, they could stay non-highlighted (the use=
s, that is; the<br>
&gt;=C2=A0 =C2=A0 =C2=A0declarations are usually easy to find using queries=
).<br>
&gt; <br>
&gt; <br>
&gt; Thanks for the detailed explanation. It&#39;s unfortunate timing, beca=
use I <br>
&gt; published a rework of the faces on MELPA so long and a few people are =
<br>
&gt; trying it out. It is a total rework using the faces a bit better.=C2=
=A0 I can <br>
&gt; submit the patch later today and start the conversation from there?<br=
>
<br>
I guess I expected that if the mode has been added to the core then the <br=
>
development is led here too. And modes maintained externally live more <br>
easily in ELPA. Anyway, we are where we are.<br>
<br>
I see that the latest work <br>
(<a href=3D"https://github.com/wkirschbaum/elixir-ts-mode/pull/36" rel=3D"n=
oreferrer" target=3D"_blank">https://github.com/wkirschbaum/elixir-ts-mode/=
pull/36</a>) anticipated at <br>
least some of my comments.<br>
<br>
Remainder:<br>
<br>
1) font-lock-variable-name-face is intended for declarations and perhaps <b=
r>
initial assignments (where it&#39;s also an implicit declaration), but for =
<br>
other variable references it&#39;s better to use <br>
font-lock-variable-use-face. With my test file, I see examples to the <br>
contrary, even though some attempt to use the latter face had been made <br=
>
(inside the &#39;elixir-function-call&#39; feature&#39;s query).<br></block=
quote><div><br></div><div>Thanks, this has been fixed. <br></div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
2) Moving highlighting of function calls and variable (and/or property) <br=
>
references to the 4th feature level. Looking at your font-lock rules, it <b=
r>
seems like the elixir-function-call matches is more targeted than the <br>
elixir-variable one, but still the other built-in modes put both at 4, <br>
so it would be good for uniformity. Function definitions (and variable <br>
definitions/declarations, if they&#39;re highlighted separately) can remain=
 <br>
in the &#39;declaration&#39; or &#39;definition&#39; feature which is put i=
n a lower <br>
feature level (e.g. ruby/js/typescript modes have it on level 1).<br></bloc=
kquote><div><br></div><div>Level 4 is strange to me, because the default is=
 3.=C2=A0 I read the docs and tried to=C2=A0</div><div>follow it with the n=
ew changes, but was hesitant to remove much from the=C2=A0</div><div>highli=
ghting as not many people might discover there is a 4th level.=C2=A0 Then a=
gain, if there is a query it</div><div>is pretty easy just to communicate t=
his.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex">
<br>
Something else I would recommend:<br>
<br>
3) Removing the &#39;-face&#39; suffix from the face names. This is the bes=
t <br>
practice across most modes, and it&#39;s something the manual entry for <br=
>
&#39;defface&#39; recommends:<br>
<br>
=C2=A0 =C2=A0You should not quote the symbol face, and it should not end in=
 <br>
=E2=80=98-face=E2=80=99 (that would be redundant).<br>
<br>
Face names inside font-lock.el are a historical exception (and we <br>
followed it when adding new faces recently), but if you search for <br>
&#39;defface&#39; inside the Emacs codebase, such names are in the minority=
.<br></blockquote><div><br></div><div>Okay thanks, I had a look and it make=
s sense.=C2=A0 I see a new mode with the same -face suffixes.=C2=A0 <br></d=
iv><div>The defface docs does not mention this, so might be a good idea to =
add it there?=C2=A0=C2=A0</div><div>I am not entirely sure what &quot;you s=
hould not quote the symbol face&quot; means wrt to the changes, because=C2=
=A0</div><div>it does not look like I am quoting it. <br></div><div>=C2=A0<=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I haven&#39;t done too much testing myself. Perhaps Andrey will take the <b=
r>
upstream version for a spin. Or we&#39;ll wait for the changes to be merged=
 <br>
here and continue.<br>
</blockquote></div></div>

--000000000000cee100060aeb39bc--

X-Loop: help-debbugs@HIDDEN
Subject: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Resent-From: Dmitry Gutov <dmitry@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 25 Nov 2023 00:23:02 +0000
Resent-Message-ID: <handler.67246.B67246.170087172511274 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 67246
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Wilhelm Kirschbaum <wkirschbaum@HIDDEN>
Cc: Andrey Listopadov <andreyorst@HIDDEN>, 67246 <at> debbugs.gnu.org
Received: via spool by 67246-submit <at> debbugs.gnu.org id=B67246.170087172511274
          (code B ref 67246); Sat, 25 Nov 2023 00:23:02 +0000
Received: (at 67246) by debbugs.gnu.org; 25 Nov 2023 00:22:05 +0000
Received: from localhost ([127.0.0.1]:37508 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1r6gQs-0002vk-9z
	for submit <at> debbugs.gnu.org; Fri, 24 Nov 2023 19:22:05 -0500
Received: from out2-smtp.messagingengine.com ([66.111.4.26]:54529)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <dmitry@HIDDEN>) id 1r6gQn-0002vA-Ez
 for 67246 <at> debbugs.gnu.org; Fri, 24 Nov 2023 19:22:01 -0500
Received: from compute7.internal (compute7.nyi.internal [10.202.2.48])
 by mailout.nyi.internal (Postfix) with ESMTP id 34B6D5C01D3;
 Fri, 24 Nov 2023 19:21:47 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162])
 by compute7.internal (MEProxy); Fri, 24 Nov 2023 19:21:47 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc
 :cc:content-transfer-encoding:content-type:content-type:date
 :date:from:from:in-reply-to:in-reply-to:message-id:mime-version
 :references:reply-to:sender:subject:subject:to:to; s=fm3; t=
 1700871707; x=1700958107; bh=nxqFvC02tr1mCCN0+sGv/ax81i/1f2oaPq8
 HkgpxZlY=; b=jacrR18WAek2/qwqRgciF+YT1e6FkKTAGIPZLk356cYCnqBZxpx
 vQvdRfkRfs9b71xt8aOYsinRSPBCPUrG7ls54ytxxWs1y01wd0xpF5zziIupHI/P
 Tn55t2qLjTID1Bqgq4hIHS1qdAYs+n3KNy3iJueEABfV40nZ+6Jemy8pXnjAxCo6
 wE9OKwA1y2nvH6zglJsqaxUMJHROnm8+0pfT1q5cWo/3bpTx8dXtS+qGREcDYADD
 wZojEZURECpoQzZUz/IXNA2OXe4c5+OUMMmmfxYgqcPk47lEXBPX8L6nl1lkDQp1
 e5o4nTZCMDku/rT4h2FS7uy3+1TYu+266Og==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:cc:content-transfer-encoding
 :content-type:content-type:date:date:feedback-id:feedback-id
 :from:from:in-reply-to:in-reply-to:message-id:mime-version
 :references:reply-to:sender:subject:subject:to:to:x-me-proxy
 :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=
 1700871707; x=1700958107; bh=nxqFvC02tr1mCCN0+sGv/ax81i/1f2oaPq8
 HkgpxZlY=; b=2KNzSsQHwnRj4CUAfowgNT/ZDL3bA/iUCF/OLsN8O6VMP72+VFK
 GTx4Hh21Yy924bn5gOKx3fJBKo/VXED/1xOq+dxwMP0itzM+jm4GSkUUZ5PMhrr9
 wEpaM8xaUPMOF8Vu/5QaKKlGgKBdAcs3d+q5UBnGAPGnaaqVbvqNQieRUL9rMKSl
 47KlY09WkVyKbZZE18E7qse47d7esEg19uUI0bwIcO5zZny5C/rkrk6yJ2gmafFK
 UXyU+Ht3LyXR4MwY7kSTGsR4swWWw/kHv/WyuEhJlrCJevRBvL6BQIsCNNZu2kzd
 JOCZihH2VIIFoGLv+s0C4CaMLlw3S2iTL/Q==
X-ME-Sender: <xms:Gj5hZR1CCeFMIH8UpdGHH2qgRwPV3xG3e8hLV5WEwvA5j79tLBt3Xw>
 <xme:Gj5hZYFQCYP71G8Z5yLJ0Ozl9Ixdc9yMJ3uuT1R55fpifWtkdcfq0cor1Mmjk8BWu
 OeTIk53yvCE3eFVprg>
X-ME-Received: <xmr:Gj5hZR6FlzV2NnW9z4jZBRpANN31zMmGQQU4Itr--GYT053QvWCs6e76LB2iMqUBgmzFFQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudehiedgvddvucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
 uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
 cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtfeejnecuhfhrohhmpeffmhhi
 thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth
 htvghrnhepjeejhfehvddukedvjedtgfeiveevgeeghfetkeehkeelieefffffgfekgfdu
 tddvnecuffhomhgrihhnpehgihhthhhusgdrtghomhdprhgvugguihhtrdgtohhmnecuve
 hluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepughmihhtrhih
 sehguhhtohhvrdguvghv
X-ME-Proxy: <xmx:Gj5hZe0NqPNEfJ6hlzG0sX9NZZNk7D5MzcAH5jdOOqqSu75LqHOVJg>
 <xmx:Gj5hZUGg0FNlSnDn51tc1vYkoeLQBiAwTyOWN7XBtwr4CzDIpB9_mA>
 <xmx:Gj5hZf89obqx6HEjMbxvYzi71gv_Mydt9NHi1utaCye3UFyLS52aTA>
 <xmx:Gz5hZeMJ6BoyVfrMCOhl-dOZi0eVcrQ_kVvvf-IHGSh_5Q95Kih6-Q>
Feedback-ID: i0e71465a:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri,
 24 Nov 2023 19:21:45 -0500 (EST)
Message-ID: <9ae8eb33-fd8b-f8d6-dd7f-79f8d4464a51@HIDDEN>
Date: Sat, 25 Nov 2023 02:21:42 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.13.0
Content-Language: en-US
References: <87y1ewgnn7.fsf@HIDDEN>
 <e54987bb-5d2a-36b2-9ee3-fc4e3832f06c@HIDDEN>
 <CAOS0-34j_6=QYEVokunwM89F_v7xieWjpnkvGf_-yhBa+yj9Yw@HIDDEN>
 <c0ca3975-2930-dbcd-ac44-03d511309b8e@HIDDEN>
 <CAOS0-34r3DSEWN2cGGQHdvn71z-T1=bV9WCWmd322HxesdwLHQ@HIDDEN>
From: Dmitry Gutov <dmitry@HIDDEN>
In-Reply-To: <CAOS0-34r3DSEWN2cGGQHdvn71z-T1=bV9WCWmd322HxesdwLHQ@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.9 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.9 (---)

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.
> 

X-Loop: help-debbugs@HIDDEN
Subject: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Resent-From: Andrey Listopadov <andreyorst@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 25 Nov 2023 09:23:02 +0000
Resent-Message-ID: <handler.67246.B67246.17009041793506 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 67246
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dmitry@HIDDEN>
Cc: Wilhelm Kirschbaum <wkirschbaum@HIDDEN>, 67246 <at> debbugs.gnu.org
Received: via spool by 67246-submit <at> debbugs.gnu.org id=B67246.17009041793506
          (code B ref 67246); Sat, 25 Nov 2023 09:23:02 +0000
Received: (at 67246) by debbugs.gnu.org; 25 Nov 2023 09:22:59 +0000
Received: from localhost ([127.0.0.1]:37798 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1r6osM-0000uU-IT
	for submit <at> debbugs.gnu.org; Sat, 25 Nov 2023 04:22:58 -0500
Received: from mail-ej1-x634.google.com ([2a00:1450:4864:20::634]:60810)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <andreyorst@HIDDEN>) id 1r6osJ-0000uF-2R
 for 67246 <at> debbugs.gnu.org; Sat, 25 Nov 2023 04:22:57 -0500
Received: by mail-ej1-x634.google.com with SMTP id
 a640c23a62f3a-a0b65cbf096so41288966b.1
 for <67246 <at> debbugs.gnu.org>; Sat, 25 Nov 2023 01:22:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1700904164; x=1701508964; darn=debbugs.gnu.org;
 h=mime-version:message-id:in-reply-to:date:subject:cc:to:from
 :user-agent:references:from:to:cc:subject:date:message-id:reply-to;
 bh=VTP4YXOpD6QhX8mn2so/e28QLHiH1Y+WV83WRyjupfE=;
 b=Ds14QYyFhv/uyCsjdtq6oAP5uch2SD7VnNiKWMMnGF1dRVlu8I0dQrhyWRVihrMyuB
 Mwsspi5UMExvXfqBJELZcnwJntmWJgur3eQwtTdzzCDpzL886KtPqXTf7NcUlXVVQ1nY
 Vz6eYJ8XEjHvljqMSiQvWdo498kL7vFwiORt768q8XtONnX+t+AOR22+Dtk4iQqoI1ef
 34YiB3soYJ6nl0IA1VC8FRoHZTIto06Cv1z/aEDobh+JVs90L6NE65DaTKkU9Gr10NB/
 fHlyOdxgitOQeHV/iOpudYrlsILBUqazQ9wfaSk0QwOSXbyJ3hWsr4jJQ9kZdq4NUryL
 poFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1700904164; x=1701508964;
 h=mime-version:message-id:in-reply-to:date:subject:cc:to:from
 :user-agent:references:x-gm-message-state:from:to:cc:subject:date
 :message-id:reply-to;
 bh=VTP4YXOpD6QhX8mn2so/e28QLHiH1Y+WV83WRyjupfE=;
 b=Rycoc5x0ytX+Da7Jh1JIPCYF+uBqrjYtuDQi/el+SC7v7VcBYX7oakUGTYuyAkH7Is
 tPxbqkobB6X/MxglTFBau53x9EDcSS77aXrNl4/yC+Q3sSGI5yn0QPJF8U5C7PyxzZtk
 Wvj+sGalrjqIJWMZTBm6tX59DIrdw7w5qFA9O1QaXC//XA2VKrR/TcEIZlCus+Cj6aR2
 ojJ8/iPSZYgv1GSbdziM+/c4NAMW18LD+1GfiEWTHOhZ35DjnJ3Ob3Nvu433xzPhBFRD
 2sTZX48X38Cby2xkBDZOhOeN0vIUZRZkM6hwgmHKL5DRsLPV6AN7WuoJMOChK0VWIsjU
 odmw==
X-Gm-Message-State: AOJu0YzhdRDlVnCmjekgx+qYXDQ5fLZnUQnh3nLKdARJ9rnfiO7d2KZj
 oAeGf0nqdGwhxSdL+GoMdV4SQgfPmuI=
X-Google-Smtp-Source: AGHT+IE1gzPlJMZGizS5MR9bbxyLp2XDPR98OAz/vUDLjY146Md9RCfpLmVn0TJt+UZJ38Zj38F5/Q==
X-Received: by 2002:a17:906:e99:b0:a04:b801:66f7 with SMTP id
 p25-20020a1709060e9900b00a04b80166f7mr4548892ejf.23.1700904163881; 
 Sat, 25 Nov 2023 01:22:43 -0800 (PST)
Received: from toolbox.smtp.gmail.com
 (broadband-46-242-11-135.ip.moscow.rt.ru. [46.242.11.135])
 by smtp.gmail.com with ESMTPSA id
 t24-20020a17090616d800b009ffb4af0505sm3194818ejd.104.2023.11.25.01.22.42
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sat, 25 Nov 2023 01:22:43 -0800 (PST)
References: <87y1ewgnn7.fsf@HIDDEN>
 <e54987bb-5d2a-36b2-9ee3-fc4e3832f06c@HIDDEN>
 <CAOS0-34j_6=QYEVokunwM89F_v7xieWjpnkvGf_-yhBa+yj9Yw@HIDDEN>
 <c0ca3975-2930-dbcd-ac44-03d511309b8e@HIDDEN>
 <CAOS0-34r3DSEWN2cGGQHdvn71z-T1=bV9WCWmd322HxesdwLHQ@HIDDEN>
 <9ae8eb33-fd8b-f8d6-dd7f-79f8d4464a51@HIDDEN>
User-agent: mu4e 1.8.11; emacs 30.0.50
From: Andrey Listopadov <andreyorst@HIDDEN>
Date: Sat, 25 Nov 2023 11:33:38 +0300
In-reply-to: <9ae8eb33-fd8b-f8d6-dd7f-79f8d4464a51@HIDDEN>
Message-ID: <87a5r2p4pq.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


Dmitry Gutov <dmitry@HIDDEN> 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'.

X-Loop: help-debbugs@HIDDEN
Subject: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Resent-From: Dmitry Gutov <dmitry@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 25 Nov 2023 23:27:01 +0000
Resent-Message-ID: <handler.67246.B67246.17009548007224 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 67246
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Andrey Listopadov <andreyorst@HIDDEN>
Cc: Wilhelm Kirschbaum <wkirschbaum@HIDDEN>, 67246 <at> debbugs.gnu.org
Received: via spool by 67246-submit <at> debbugs.gnu.org id=B67246.17009548007224
          (code B ref 67246); Sat, 25 Nov 2023 23:27:01 +0000
Received: (at 67246) by debbugs.gnu.org; 25 Nov 2023 23:26:40 +0000
Received: from localhost ([127.0.0.1]:40454 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1r722p-0001sS-Jd
	for submit <at> debbugs.gnu.org; Sat, 25 Nov 2023 18:26:39 -0500
Received: from out1-smtp.messagingengine.com ([66.111.4.25]:58413)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <dmitry@HIDDEN>) id 1r722n-0001s9-5k
 for 67246 <at> debbugs.gnu.org; Sat, 25 Nov 2023 18:26:38 -0500
Received: from compute7.internal (compute7.nyi.internal [10.202.2.48])
 by mailout.nyi.internal (Postfix) with ESMTP id 292935C01D1;
 Sat, 25 Nov 2023 18:26:26 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162])
 by compute7.internal (MEProxy); Sat, 25 Nov 2023 18:26:26 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc
 :cc:content-transfer-encoding:content-type:content-type:date
 :date:from:from:in-reply-to:in-reply-to:message-id:mime-version
 :references:reply-to:sender:subject:subject:to:to; s=fm3; t=
 1700954786; x=1701041186; bh=CZEOoMR/iPVx01Hu+Mx6NItMQJ+4vCCXR1s
 TK1PdYXM=; b=IIB5CcnUDSzXFUTigp9qzeoAm2+X/hPQENsY8nkUfuhUYvg1F3c
 kZlmecd8z4NwT6jZUiWUPWziD+dyzQFto4zIEERp19NsNStsRRvjzWV96dZDEgxG
 Neta11BYoCnF8Lqp00vVSa8iohxfGI3qfLULb8SfhkRGIZEDAY7BMOuqLt4/z5vF
 ZjVGN9YYbtKbqVUIIQe2O2eEClPpg52WxKQA4xP5m0eV3SBafZ6UPpI8OGDmNf+I
 qUxNsV///RsQmRhRFrxFprNX3A6WSHEtm0lhCTdjWVPSlJolRNdzTFedr4QR5VfF
 0WOfBSTTT8gnDGzpFr0laSWKmQPGdotd0UA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:cc:content-transfer-encoding
 :content-type:content-type:date:date:feedback-id:feedback-id
 :from:from:in-reply-to:in-reply-to:message-id:mime-version
 :references:reply-to:sender:subject:subject:to:to:x-me-proxy
 :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=
 1700954786; x=1701041186; bh=CZEOoMR/iPVx01Hu+Mx6NItMQJ+4vCCXR1s
 TK1PdYXM=; b=T8uwzXBiLGep313s35/706UQOshrSwOEEtKqWj+chydWojvnZfq
 UYOqerI/1zILpFn6wG+c2lxpSL5nWyTLDu5ardvc0032na0u1LPiX3bnUK5BLY7H
 t3x7ZZpSH1pzn3Yaw1w+nOtCvXtemgS3TbNeXsu8xC+XGyFtIvonwVGv2XBZwIgs
 ZARktjEpgtNW2AN+4XrolFH7kwX1Qdj8MgxGYJRdHvUPLrLgJa6RxtorJSwC+PpK
 R4mLlfDEDCPpS/5Q0fjTBL8BMCzuHE20L3uKGSb6hh0737NLrsGqvqDv3aNkc8Qb
 B2wVTvCpAV3OmdYJRBd/zDVv8btrzNX2szg==
X-ME-Sender: <xms:oYJiZZwl02snZIXO8e1GluT1O3VkuxaSvP1YkUHyEfQ6UWvFCWnLVQ>
 <xme:oYJiZZRHd9jojkH1Kw2dGUxwjj_1cmRG9BRkXwerlOXIqP06StUI2i7Wjyf1fFxuI
 xj6JxubMO0PZsxf150>
X-ME-Received: <xmr:oYJiZTXK6KDrxfIy8_w0WVoEdUttJm6QiuZuNlbPZcijt_ufuH4Q4yD6APixeSF-NlG73A>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudehkedguddtucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
 uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
 cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi
 thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth
 htvghrnhephffhleeifffgveevudeugfeifeeuffevgfeutdeitefhiefgtedvheeuvedv
 vdefnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucevlhhushhtvghrufhiiigvpe
 dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumhhithhrhiesghhuthhovhdruggvvh
X-ME-Proxy: <xmx:oYJiZbgiiUzvc3nOXc2vUG8hpby5PhG3Zlw9d3bW6Gs_82W6oPpIqw>
 <xmx:oYJiZbDceJnUlaTTZR4Dt8W_nSwzvKKvtvkOUVOL0XYUpoAxH5pI8g>
 <xmx:oYJiZUKz4oHn4ZrHcYEGNmozVDt7xXptm31yDrtx4cOQwBl6e5R9RA>
 <xmx:ooJiZQ7NLHIhSg5w9cdj4nSouzES-OguQofsSiLPVPpyHdokNp8yMw>
Feedback-ID: i0e71465a:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat,
 25 Nov 2023 18:26:24 -0500 (EST)
Message-ID: <d3233eeb-2afc-b9fb-c7a7-4c5d5aa764c9@HIDDEN>
Date: Sun, 26 Nov 2023 01:26:21 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.13.0
Content-Language: en-US
References: <87y1ewgnn7.fsf@HIDDEN>
 <e54987bb-5d2a-36b2-9ee3-fc4e3832f06c@HIDDEN>
 <CAOS0-34j_6=QYEVokunwM89F_v7xieWjpnkvGf_-yhBa+yj9Yw@HIDDEN>
 <c0ca3975-2930-dbcd-ac44-03d511309b8e@HIDDEN>
 <CAOS0-34r3DSEWN2cGGQHdvn71z-T1=bV9WCWmd322HxesdwLHQ@HIDDEN>
 <9ae8eb33-fd8b-f8d6-dd7f-79f8d4464a51@HIDDEN> <87a5r2p4pq.fsf@HIDDEN>
From: Dmitry Gutov <dmitry@HIDDEN>
In-Reply-To: <87a5r2p4pq.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -2.9 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.9 (---)

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).

X-Loop: help-debbugs@HIDDEN
Subject: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Resent-From: Wilhelm Kirschbaum <wkirschbaum@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 27 Nov 2023 18:09:01 +0000
Resent-Message-ID: <handler.67246.B67246.17011085286071 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 67246
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dmitry@HIDDEN>
Cc: Andrey Listopadov <andreyorst@HIDDEN>, 67246 <at> debbugs.gnu.org
Received: via spool by 67246-submit <at> debbugs.gnu.org id=B67246.17011085286071
          (code B ref 67246); Mon, 27 Nov 2023 18:09:01 +0000
Received: (at 67246) by debbugs.gnu.org; 27 Nov 2023 18:08:48 +0000
Received: from localhost ([127.0.0.1]:44762 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1r7g2J-0001Zq-6Y
	for submit <at> debbugs.gnu.org; Mon, 27 Nov 2023 13:08:48 -0500
Received: from mail-wr1-x42e.google.com ([2a00:1450:4864:20::42e]:48402)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <wkirschbaum@HIDDEN>) id 1r7g2G-0001Zb-03
 for 67246 <at> debbugs.gnu.org; Mon, 27 Nov 2023 13:08:45 -0500
Received: by mail-wr1-x42e.google.com with SMTP id
 ffacd0b85a97d-332ce50450dso3006842f8f.1
 for <67246 <at> debbugs.gnu.org>; Mon, 27 Nov 2023 10:08:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1701108511; x=1701713311; darn=debbugs.gnu.org;
 h=mime-version:message-id:in-reply-to:date:subject:cc:to:from
 :user-agent:references:from:to:cc:subject:date:message-id:reply-to;
 bh=H7k06tn3J34UlSFKW+nERUqxX7YHGLM4rbBxNps6QGI=;
 b=RoyH3s3H6si5MlL48t9elCCVpQEyVqs1YrtxOy6wCu0BXOVlTnrJkWzi+EkIIU/tpk
 887oNh2FQ5YYsvKRH8blYpheymYBCj2xS95negdyzy7BjZVRiXp2YNCHcDAdyjxtZOJO
 q9wVISe5XrtcrDgZym2yzI/krSm8UL94VtKBSuBJ6Vd5D2GOyaisWAcbghWH7LU0wLv2
 z4WLaRydf5lmCA3ep3CPN8LTO1eRlraCXRfxRwl2RH1IykA8nzrsIND/HerBeWdWPYxO
 qJTsNw6fiHX83O4dJSm/b0Y/UrbVf5RGzfCVfJMZP9QVe3P/4S3p83EVxoacCRzjxnS1
 q5TA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1701108511; x=1701713311;
 h=mime-version:message-id:in-reply-to:date:subject:cc:to:from
 :user-agent:references:x-gm-message-state:from:to:cc:subject:date
 :message-id:reply-to;
 bh=H7k06tn3J34UlSFKW+nERUqxX7YHGLM4rbBxNps6QGI=;
 b=o8w2AM/R+VxIerFsT/8wN8xyisEHx2h3vZQ0HqBqPz3fF7PlAW/FSgKzOywtOcvaN4
 aAEjzmWllMTZds6taa5NlxnY4Ni3nACNNFwuBzQ0QL5PLkTeECHwKahbrxs3fytvCDCQ
 Hrlcn8uxMq5oKLSeP/V9oHnXqGiVr68SThLuQtzxQLDMHqTFxH2XIP62ClBnCkeCA0pn
 uCKCfxg2Fl6vhMF3TCguWqOE7+0Bszmuanf54ORmaOP4JNJiF7GxDP9RnFZpOOrbTI7T
 D3rLMeI4J1tspgvzfV1M2c1NNeSOZwAWCsScTQx3ez47uZYRdzUcTHjSy0v/ckdGo6oN
 aZTg==
X-Gm-Message-State: AOJu0Ywl4+J4cKNl3eaJo70I5hG3D9vSUkUdNVLa7GwmbOhnzFsv3HPo
 eYFi5SFuYiD3Z9OlX/jnVKAlFbDfs0I=
X-Google-Smtp-Source: AGHT+IGyXsFL9kOX6JSTJFp2mz1D356ikYK93+7J1QuNE2gucg9T2WWlvDbqB8LkIu6JuYNiW6arbQ==
X-Received: by 2002:a05:600c:458f:b0:40b:2afd:70a6 with SMTP id
 r15-20020a05600c458f00b0040b2afd70a6mr8567022wmo.1.1701108510604; 
 Mon, 27 Nov 2023 10:08:30 -0800 (PST)
Received: from melissa.local ([2c0f:ef18:1431:0:b09:9616:db04:c248])
 by smtp.gmail.com with ESMTPSA id
 s7-20020a05600c45c700b0040b37f1079dsm13253054wmo.29.2023.11.27.10.08.28
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 27 Nov 2023 10:08:30 -0800 (PST)
References: <87y1ewgnn7.fsf@HIDDEN>
 <e54987bb-5d2a-36b2-9ee3-fc4e3832f06c@HIDDEN>
 <CAOS0-34j_6=QYEVokunwM89F_v7xieWjpnkvGf_-yhBa+yj9Yw@HIDDEN>
 <c0ca3975-2930-dbcd-ac44-03d511309b8e@HIDDEN>
 <CAOS0-34r3DSEWN2cGGQHdvn71z-T1=bV9WCWmd322HxesdwLHQ@HIDDEN>
 <9ae8eb33-fd8b-f8d6-dd7f-79f8d4464a51@HIDDEN>
 <87a5r2p4pq.fsf@HIDDEN>
 <d3233eeb-2afc-b9fb-c7a7-4c5d5aa764c9@HIDDEN>
User-agent: mu4e 1.9.3; emacs 30.0.50
From: Wilhelm Kirschbaum <wkirschbaum@HIDDEN>
Date: Mon, 27 Nov 2023 19:59:37 +0200
In-reply-to: <d3233eeb-2afc-b9fb-c7a7-4c5d5aa764c9@HIDDEN>
Message-ID: <87bkbfkr1h.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--=-=-=
Content-Type: text/plain; format=flowed


Dmitry Gutov <dmitry@HIDDEN> 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.


--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment;
 filename=0001-Various-improvements-to-font-lock-settings-for-elixi.patch

From ef3e6b3106cabdcaa000503a9b2c227110be36f3 Mon Sep 17 00:00:00 2001
From: Wilhelm H Kirschbaum <wkirschbaum@HIDDEN>
Date: Wed, 15 Nov 2023 20:41:08 +0200
Subject: [PATCH] Various improvements to font-lock-settings for elixir-ts-mode

Changes and made from conversations from the Elixir slack channel,
the github issue
https://github.com/wkirschbaum/elixir-ts-mode/issues/35 and bug#67246.

* lisp/progmodes/elixir-ts-mode.el
(elixir-ts--font-lock-settings): Update features.
(elixir-ts-mode): Update treesit-font-lock-feature-list.
(elixir-ts-font-comment-doc-identifier-face): Rename to
elixir-ts-comment-doc-identifier.
(elixir-ts-font-comment-doc-attribute-face): Rename to
elixir-ts-comment-doc-attribute.
(elixir-ts-font-sigil-name-face): Rename to elixir-ts-sigil-name.
(elixir-ts-atom-key-face)
(elixir-ts-keyword-key-face)
(elixir-ts-attribute-face): Add new custom face.
---
 lisp/progmodes/elixir-ts-mode.el | 323 ++++++++++++++++++-------------
 1 file changed, 191 insertions(+), 132 deletions(-)

diff --git a/lisp/progmodes/elixir-ts-mode.el b/lisp/progmodes/elixir-ts-mode.el
index c687ed9d06b..62429308d96 100644
--- a/lisp/progmodes/elixir-ts-mode.el
+++ b/lisp/progmodes/elixir-ts-mode.el
@@ -86,17 +86,35 @@ elixir-ts-mode-hook
   :group 'elixir-ts
   :version "30.1")
 
-(defface elixir-ts-font-comment-doc-identifier-face
+(defface elixir-ts-comment-doc-identifier
   '((t (:inherit font-lock-doc-face)))
-  "Face used for @comment.doc tags in Elixir files.")
+  "Face used for doc identifiers in Elixir files."
+  :group 'elixir-ts)
 
-(defface elixir-ts-font-comment-doc-attribute-face
+(defface elixir-ts-comment-doc-attribute
   '((t (:inherit font-lock-doc-face)))
-  "Face used for @comment.doc.__attribute__ tags in Elixir files.")
+  "Face used for doc attributes in Elixir files."
+  :group 'elixir-ts)
 
-(defface elixir-ts-font-sigil-name-face
+(defface elixir-ts-sigil-name
   '((t (:inherit font-lock-string-face)))
-  "Face used for @__name__ tags in Elixir files.")
+  "Face used for sigils in Elixir files."
+  :group 'elixir-ts)
+
+(defface elixir-ts-atom
+  '((t (:inherit font-lock-constant-face)))
+  "Face used for atoms in Elixir files."
+  :group 'elixir-ts)
+
+(defface elixir-ts-keyword-key
+  '((t (:inherit elixir-ts-atom)))
+  "Face used for keyword keys in Elixir files."
+  :group 'elixir-ts)
+
+(defface elixir-ts-attribute
+  '((t (:inherit font-lock-preprocessor-face)))
+  "Face used for attributes in Elixir files."
+  :group 'elixir-ts)
 
 (defconst elixir-ts--sexp-regexp
   (rx bol
@@ -114,7 +132,10 @@ elixir-ts--definition-keywords
     "defoverridable" "defp" "defprotocol" "defstruct"))
 
 (defconst elixir-ts--definition-keywords-re
-  (concat "^" (regexp-opt elixir-ts--definition-keywords) "$"))
+  (concat "^" (regexp-opt
+               (append elixir-ts--definition-keywords
+                       elixir-ts--test-definition-keywords))
+          "$"))
 
 (defconst elixir-ts--kernel-keywords
   '("alias" "case" "cond" "else" "for" "if" "import" "quote"
@@ -334,56 +355,73 @@ elixir-ts--indent-rules
                   (treesit-node-start
                    (treesit-node-parent
                     (treesit-node-at (point) 'elixir))))
-                  0)))))
+                0)))))
 
 (defvar elixir-ts--font-lock-settings
   (treesit-font-lock-rules
    :language 'elixir
-   :feature 'elixir-comment
-   '((comment) @font-lock-comment-face)
-
-   :language 'elixir
-   :feature 'elixir-string
-   :override t
-   '([(string) (charlist)] @font-lock-string-face)
-
+   :feature 'elixir-function-name
+   `((call target: (identifier) @target-identifier
+           (arguments (identifier) @font-lock-function-name-face)
+           (:match ,elixir-ts--definition-keywords-re @target-identifier))
+     (call target: (identifier) @target-identifier
+           (arguments
+            (call target: (identifier) @font-lock-function-name-face))
+           (:match ,elixir-ts--definition-keywords-re @target-identifier))
+     (call target: (identifier) @target-identifier
+           (arguments
+            (binary_operator
+             left: (call target: (identifier) @font-lock-function-name-face)))
+           (:match ,elixir-ts--definition-keywords-re @target-identifier))
+     (call target: (identifier) @target-identifier
+           (arguments (identifier) @font-lock-function-name-face)
+           (do_block)
+           (:match ,elixir-ts--definition-keywords-re @target-identifier))
+     (call target: (identifier) @target-identifier
+           (arguments
+            (call target: (identifier) @font-lock-function-name-face))
+           (do_block)
+           (:match ,elixir-ts--definition-keywords-re @target-identifier))
+     (call target: (identifier) @target-identifier
+           (arguments
+            (binary_operator
+             left: (call target: (identifier) @font-lock-function-name-face)))
+           (do_block)
+           (:match ,elixir-ts--definition-keywords-re @target-identifier))
+     (unary_operator
+      operator: "@"
+      (call (arguments
+             (binary_operator
+              left: (call target: (identifier) @font-lock-function-name-face))))))
+
+   ;; A function definition like "def _foo" is valid, but we should
+   ;; not apply the comment-face unless its a non-function identifier, so
+   ;; the comment matches has to be after the function matches.
    :language 'elixir
-   :feature 'elixir-string-interpolation
-   :override t
-   '((string
-      [
-       quoted_end: _ @font-lock-string-face
-       quoted_start: _ @font-lock-string-face
-       (quoted_content) @font-lock-string-face
-       (interpolation
-        "#{" @font-lock-regexp-grouping-backslash "}"
-        @font-lock-regexp-grouping-backslash)
-       ])
-     (charlist
-      [
-       quoted_end: _ @font-lock-string-face
-       quoted_start: _ @font-lock-string-face
-       (quoted_content) @font-lock-string-face
-       (interpolation
-        "#{" @font-lock-regexp-grouping-backslash "}"
-        @font-lock-regexp-grouping-backslash)
-       ]))
+   :feature 'elixir-comment
+   '((comment) @font-lock-comment-face
+     ((identifier) @font-lock-comment-face
+      (:match "^_[a-z]\\|^_$" @font-lock-comment-face)))
 
    :language 'elixir
-   :feature 'elixir-keyword
-   `(,elixir-ts--reserved-keywords-vector
-     @font-lock-keyword-face
-     (binary_operator
-      operator: _ @font-lock-keyword-face
-      (:match ,elixir-ts--reserved-keywords-re @font-lock-keyword-face)))
+   :feature 'elixir-variable
+   `((call target: (identifier)
+           (arguments
+            (binary_operator
+             (call target: (identifier)
+                   (arguments ((identifier) @font-lock-variable-use-face))))))
+     (call target: (identifier)
+           (arguments
+            (call target: (identifier)
+                  (arguments ((identifier)) @font-lock-variable-use-face))))
+     (dot left: (identifier) @font-lock-variable-use-face operator: "." ))
 
    :language 'elixir
    :feature 'elixir-doc
-   :override t
    `((unary_operator
-      operator: "@" @elixir-ts-font-comment-doc-attribute-face
+      operator: "@" @elixir-ts-comment-doc-attribute
       operand: (call
-                target: (identifier) @elixir-ts-font-comment-doc-identifier-face
+                target: (identifier) @elixir-ts-comment-doc-identifier
                 ;; Arguments can be optional, so adding another
                 ;; entry without arguments.
                 ;; If we don't handle then we don't apply font
@@ -395,109 +433,128 @@ elixir-ts--font-lock-settings
                   (charlist) @font-lock-doc-face
                   (sigil) @font-lock-doc-face
                   (boolean) @font-lock-doc-face
+                  (keywords) @font-lock-doc-face
                   ]))
       (:match ,elixir-ts--doc-keywords-re
-              @elixir-ts-font-comment-doc-identifier-face))
+              @elixir-ts-comment-doc-identifier))
      (unary_operator
-      operator: "@" @elixir-ts-font-comment-doc-attribute-face
+      operator: "@" @elixir-ts-comment-doc-attribute
       operand: (call
-                target: (identifier) @elixir-ts-font-comment-doc-identifier-face)
+                target: (identifier) @elixir-ts-comment-doc-identifier)
       (:match ,elixir-ts--doc-keywords-re
-              @elixir-ts-font-comment-doc-identifier-face)))
+              @elixir-ts-comment-doc-identifier)))
 
    :language 'elixir
-   :feature 'elixir-unary-operator
-   `((unary_operator operator: "@" @font-lock-preprocessor-face
-                     operand: [
-                               (identifier)  @font-lock-preprocessor-face
-                               (call target: (identifier)
-                                     @font-lock-preprocessor-face)
-                               (boolean)  @font-lock-preprocessor-face
-                               (nil)  @font-lock-preprocessor-face
-                               ])
+   :feature 'elixir-string
+   '((interpolation
+      "#{" @font-lock-escape-face
+      "}" @font-lock-escape-face)
+     (string (quoted_content) @font-lock-string-face)
+     (quoted_keyword (quoted_content) @font-lock-string-face)
+     (charlist (quoted_content) @font-lock-string-face)
+     ["\"" "'" "\"\"\""] @font-lock-string-face)
 
-     (unary_operator operator: "&") @font-lock-function-name-face
-     (operator_identifier) @font-lock-operator-face)
+   :language 'elixir
+   :feature 'elixir-sigil
+   `((sigil
+      (sigil_name) @elixir-ts-sigil-name
+      (quoted_content) @font-lock-string-face
+      ;; HEEx and Surface templates will handled by
+      ;; heex-ts-mode if its available.
+      (:match "^[^HF]$" @elixir-ts-sigil-name))
+     @font-lock-string-face
+     (sigil
+      (sigil_name) @font-lock-regexp-face
+      (:match "^[rR]$" @font-lock-regexp-face))
+     @font-lock-regexp-face
+     (sigil
+      "~" @font-lock-string-face
+      (sigil_name) @font-lock-string-face
+      quoted_start: _ @font-lock-string-face
+      quoted_end: _ @font-lock-string-face))
 
    :language 'elixir
    :feature 'elixir-operator
-   '((binary_operator operator: _ @font-lock-operator-face)
-     (dot operator: _ @font-lock-operator-face)
-     (stab_clause operator: _ @font-lock-operator-face)
-
-     [(boolean) (nil)] @font-lock-constant-face
-     [(integer) (float)] @font-lock-number-face
-     (alias) @font-lock-type-face
-     (call target: (dot left: (atom) @font-lock-type-face))
-     (char) @font-lock-constant-face
-     [(atom) (quoted_atom)] @font-lock-type-face
-     [(keyword) (quoted_keyword)] @font-lock-builtin-face)
+   `(["!"] @font-lock-negation-char-face
+     ["%"] @font-lock-bracket-face
+     ["," ";"] @font-lock-operator-face
+     ["(" ")" "[" "]" "{" "}" "<<" ">>"] @font-lock-bracket-face)
 
    :language 'elixir
-   :feature 'elixir-call
-   `((call
-      target: (identifier) @font-lock-keyword-face
-      (:match ,elixir-ts--definition-keywords-re @font-lock-keyword-face))
-     (call
-      target: (identifier) @font-lock-keyword-face
-      (:match ,elixir-ts--kernel-keywords-re @font-lock-keyword-face))
-     (call
-      target: [(identifier) @font-lock-function-name-face
-               (dot right: (identifier) @font-lock-keyword-face)])
+   :feature 'elixir-data-type
+   '([(atom) (alias)] @font-lock-type-face
+     (keywords (pair key: (keyword) @elixir-ts-keyword-key))
+     [(keyword) (quoted_keyword)] @elixir-ts-atom
+     [(boolean) (nil)] @elixir-ts-atom
+     (unary_operator operator: "@" @elixir-ts-attribute
+                     operand: [
+                               (identifier) @elixir-ts-attribute
+                               (call target: (identifier)
+                                     @elixir-ts-attribute)
+                               (boolean) @elixir-ts-attribute
+                               (nil) @elixir-ts-attribute
+                               ])
+     (operator_identifier) @font-lock-operator-face)
+
+   :language 'elixir
+   :feature 'elixir-keyword
+   `(,elixir-ts--reserved-keywords-vector
+     @font-lock-keyword-face
+     (binary_operator
+      operator: _ @font-lock-keyword-face
+      (:match ,elixir-ts--reserved-keywords-re @font-lock-keyword-face))
+     (binary_operator operator: _ @font-lock-operator-face)
      (call
       target: (identifier) @font-lock-keyword-face
-      (arguments
-       [
-        (identifier) @font-lock-keyword-face
-        (binary_operator
-         left: (identifier) @font-lock-keyword-face
-         operator: "when")
-        ])
       (:match ,elixir-ts--definition-keywords-re @font-lock-keyword-face))
      (call
       target: (identifier) @font-lock-keyword-face
-      (arguments
-       (binary_operator
-        operator: "|>"
-        right: (identifier)))
-      (:match ,elixir-ts--definition-keywords-re @font-lock-keyword-face)))
+      (:match ,elixir-ts--kernel-keywords-re @font-lock-keyword-face)))
 
    :language 'elixir
-   :feature 'elixir-constant
-   `((binary_operator operator: "|>" right: (identifier)
-                      @font-lock-function-name-face)
-     ((identifier) @font-lock-keyword-face
-      (:match ,elixir-ts--builtin-keywords-re
-              @font-lock-keyword-face))
-     ((identifier) @font-lock-comment-face
-      (:match "^_" @font-lock-comment-face))
-     (identifier) @font-lock-function-name-face
-     ["%"] @font-lock-keyward-face
-     ["," ";"] @font-lock-keyword-face
-     ["(" ")" "[" "]" "{" "}" "<<" ">>"] @font-lock-keyword-face)
+   :feature 'elixir-function-call
+   '((call target: (identifier) @font-lock-function-call-face)
+     (unary_operator operator: "&" @font-lock-operator-face
+                     operand: (binary_operator
+                               left: (identifier)
+                               @font-lock-function-call-face
+                               operator: "/" right: (integer)))
+     (call
+      target: (dot right: (identifier) @font-lock-function-call-face))
+     (unary_operator operator: "&" @font-lock-variable-name-face
+                     operand: (integer) @font-lock-variable-name-face)
+     (unary_operator operator: "&" @font-lock-operator-face
+                     operand: (list)))
 
    :language 'elixir
-   :feature 'elixir-sigil
+   :feature 'elixir-string-escape
    :override t
-   `((sigil
-      (sigil_name) @elixir-ts-font-sigil-name-face
-      (:match "^[^HF]$" @elixir-ts-font-sigil-name-face))
-     @font-lock-string-face
-     (sigil
-      (sigil_name) @font-lock-regexp-face
-      (:match "^[rR]$" @font-lock-regexp-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)))
+   `((escape_sequence) @font-lock-escape-face)
 
    :language 'elixir
-   :feature 'elixir-string-escape
+   :feature 'elixir-number
+   '([(integer) (float)] @font-lock-number-face)
+
+   :language 'elixir
+   :feature 'elixir-variable
+   '((binary_operator left: (identifier) @font-lock-variable-name-face)
+     (binary_operator right: (identifier) @font-lock-variable-name-face)
+     (arguments ( (identifier) @font-lock-variable-name-face))
+     (tuple (identifier) @font-lock-variable-name-face)
+     (list (identifier) @font-lock-variable-name-face)
+     (pair value: (identifier) @font-lock-variable-name-face)
+     (body (identifier) @font-lock-variable-name-face)
+     (unary_operator operand: (identifier) @font-lock-variable-name-face)
+     (interpolation (identifier) @font-lock-variable-name-face)
+     (do_block (identifier) @font-lock-variable-name-face))
+
+   :language 'elixir
+   :feature 'elixir-builtin
    :override t
-   `((escape_sequence) @font-lock-regexp-grouping-backslash))
+   `(((identifier) @font-lock-builtin-face
+      (:match ,elixir-ts--builtin-keywords-re
+              @font-lock-builtin-face))))
+
   "Tree-sitter font-lock settings.")
 
 (defvar elixir-ts--treesit-range-rules
@@ -640,10 +697,12 @@ elixir-ts-mode
     ;; Font-lock.
     (setq-local treesit-font-lock-settings elixir-ts--font-lock-settings)
     (setq-local treesit-font-lock-feature-list
-                '(( elixir-comment elixir-constant elixir-doc )
-                  ( elixir-string elixir-keyword elixir-unary-operator
-                    elixir-call elixir-operator )
-                  ( elixir-sigil elixir-string-escape elixir-string-interpolation)))
+                '(( elixir-comment elixir-doc elixir-function-name)
+                  ( elixir-string elixir-keyword elixir-data-type)
+                  ( elixir-sigil elixir-variable elixir-builtin
+                    elixir-string-escape)
+                  ( elixir-function-call elixir-operator elixir-number )))
+
 
     ;; Imenu.
     (setq-local treesit-simple-imenu-settings
@@ -675,13 +734,13 @@ elixir-ts-mode
                           heex-ts--indent-rules))
 
       (setq-local treesit-font-lock-feature-list
-                  '(( elixir-comment elixir-constant elixir-doc
+                  '(( elixir-comment elixir-doc elixir-function-name
                       heex-comment heex-keyword heex-doctype )
-                    ( elixir-string elixir-keyword elixir-unary-operator
-                      elixir-call elixir-operator
-                      heex-component heex-tag heex-attribute heex-string)
-                    ( elixir-sigil elixir-string-escape
-                      elixir-string-interpolation ))))
+                    ( elixir-string elixir-keyword elixir-data-type
+                      heex-component heex-tag heex-attribute heex-string )
+                    ( elixir-sigil elixir-variable elixir-builtin
+                      elixir-string-escape)
+                    ( elixir-function-call elixir-operator elixir-number ))))
 
     (treesit-major-mode-setup)
     (setq-local syntax-propertize-function #'elixir-ts--syntax-propertize)))
-- 
2.43.0


--=-=-=--

X-Loop: help-debbugs@HIDDEN
Subject: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Resent-From: Dmitry Gutov <dmitry@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 29 Nov 2023 03:26:02 +0000
Resent-Message-ID: <handler.67246.B67246.170122831627967 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 67246
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Wilhelm Kirschbaum <wkirschbaum@HIDDEN>
Cc: Andrey Listopadov <andreyorst@HIDDEN>, 67246 <at> debbugs.gnu.org
Received: via spool by 67246-submit <at> debbugs.gnu.org id=B67246.170122831627967
          (code B ref 67246); Wed, 29 Nov 2023 03:26:02 +0000
Received: (at 67246) by debbugs.gnu.org; 29 Nov 2023 03:25:16 +0000
Received: from localhost ([127.0.0.1]:48529 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1r8BCO-0007H1-51
	for submit <at> debbugs.gnu.org; Tue, 28 Nov 2023 22:25:16 -0500
Received: from wout4-smtp.messagingengine.com ([64.147.123.20]:45145)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <dmitry@HIDDEN>) id 1r8BCK-0007Gf-BX
 for 67246 <at> debbugs.gnu.org; Tue, 28 Nov 2023 22:25:14 -0500
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41])
 by mailout.west.internal (Postfix) with ESMTP id C0B653200B9D;
 Tue, 28 Nov 2023 22:24:58 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162])
 by compute1.internal (MEProxy); Tue, 28 Nov 2023 22:24:59 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc
 :cc:content-transfer-encoding:content-type:content-type:date
 :date:from:from:in-reply-to:in-reply-to:message-id:mime-version
 :references:reply-to:sender:subject:subject:to:to; s=fm3; t=
 1701228298; x=1701314698; bh=k96PyC7tUySFRyOwQuOveEJ1w/c21wfoFiu
 aTeNasXc=; b=w/WuWsfMARWGytRKDM5ogYJNwjSsyky+fPJqft796UyB4dtBGWe
 2/2/s6iVJnSOP9E5Wkwakml+akztaTnwdhhI9q2wlUFzQUUnSm1/N5yWOKWI0vvj
 Xu//7Js6TcTWf79mC/rh7qOupj4BRrNKxcu9JFh1VpSH93dAxY2m6/u3pXeN0hP1
 7sL9GnpVJ0BNit7HpgR2HIngZ8BB40FdExD86wyEvMcv7DWVRXwlQ97EWkEC23xt
 K4HZITRSCPxVZSZN7HPzYaeZaW12ZmDlZNwIYhFsnAnTl7KPShvc9jt1WZnrCwnZ
 7tYN0jAT2vCPJAjkthzGLil8PFPJ5gJ+fZg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:cc:content-transfer-encoding
 :content-type:content-type:date:date:feedback-id:feedback-id
 :from:from:in-reply-to:in-reply-to:message-id:mime-version
 :references:reply-to:sender:subject:subject:to:to:x-me-proxy
 :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=
 1701228298; x=1701314698; bh=k96PyC7tUySFRyOwQuOveEJ1w/c21wfoFiu
 aTeNasXc=; b=zU1pIECShNOWz9hGyvDjIw/rUElBLYxGqC4wSr4/qA3ZrosuTfZ
 WodZzaZg9H0FjVWcAHdGLMir7Z5jh2uyxojVwEtpERR19oMhsUOXf2mkN08w2a/7
 rGJM9KLxc+aY45gG5pOy2MiFfM//DYZWRxqflWTFwj80YyKK48vh9w8erJLHutNr
 NO52Cw1ZVKoukjRWpzDwaOk2dSG0zp8gKeVimsA+IpOsAAnP2SoRuaisNqm5XrTH
 fHUIoKSI4y55+jiXjMKI4HvNO23y0sTDB3GChu1R+ju7cFGnR+MpeEicbUnohf1v
 FH/lEmmFhXCny6m0datTKu4qc0sChfvyKFQ==
X-ME-Sender: <xms:Ca9mZVe_NhJRpqPHPI1lGVTicPb0VR7IhYfU7VrRhUssfONSqxwFnA>
 <xme:Ca9mZTO-YQ-GyBHdNPQcxMemh1Is9izmCk2-2OM4dfylnziU7vaqtEySkHer9jrIg
 hcSq7rPHB97fMXR5JE>
X-ME-Received: <xmr:Ca9mZegl5OUmhFhCJxpSQjEXXdG9F4mdLP8wrN0BdJFko9ROSGf2ShPoXLuj517_vac-Ow>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudeigedgheejucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
 uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
 cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtfeejnecuhfhrohhmpeffmhhi
 thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth
 htvghrnhephfffheeljeffgeffueeghfekkedtfffgheejvdegjeettdduheeufffggfef
 jeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug
 hmihhtrhihsehguhhtohhvrdguvghv
X-ME-Proxy: <xmx:Ca9mZe__9UJfXTpf9Lnhe7WsHMJHKE5l5oTU9MZUTn7r4YS74fWD5A>
 <xmx:Ca9mZRt3RvVEXjo_EikU6V6Dy7Ld-3aiJURYY8-uOcWdJ6eF0vKr-A>
 <xmx:Ca9mZdGUzXWbCFfl7fP-tFY_nufQssXAmfddgbb323P3wMbLL__hkQ>
 <xmx:Cq9mZSV6jfUm2QvtWg_y1y0A0oNb5oIGIHZn2lY4Kl1PkuYGL4bQLQ>
Feedback-ID: i0e71465a:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 28 Nov 2023 22:24:56 -0500 (EST)
Message-ID: <22ea1559-f44e-933d-e60a-9caa62b376a8@HIDDEN>
Date: Wed, 29 Nov 2023 05:24:53 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.13.0
Content-Language: en-US
References: <87y1ewgnn7.fsf@HIDDEN>
 <e54987bb-5d2a-36b2-9ee3-fc4e3832f06c@HIDDEN>
 <CAOS0-34j_6=QYEVokunwM89F_v7xieWjpnkvGf_-yhBa+yj9Yw@HIDDEN>
 <c0ca3975-2930-dbcd-ac44-03d511309b8e@HIDDEN>
 <CAOS0-34r3DSEWN2cGGQHdvn71z-T1=bV9WCWmd322HxesdwLHQ@HIDDEN>
 <9ae8eb33-fd8b-f8d6-dd7f-79f8d4464a51@HIDDEN> <87a5r2p4pq.fsf@HIDDEN>
 <d3233eeb-2afc-b9fb-c7a7-4c5d5aa764c9@HIDDEN> <87bkbfkr1h.fsf@HIDDEN>
From: Dmitry Gutov <dmitry@HIDDEN>
In-Reply-To: <87bkbfkr1h.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.9 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.9 (---)

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.

X-Loop: help-debbugs@HIDDEN
Subject: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Resent-From: Andrey Listopadov <andreyorst@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 03 Dec 2023 10:58:02 +0000
Resent-Message-ID: <handler.67246.B67246.17016010226360 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 67246
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dmitry@HIDDEN>
Cc: Wilhelm Kirschbaum <wkirschbaum@HIDDEN>, 67246 <at> debbugs.gnu.org
Received: via spool by 67246-submit <at> debbugs.gnu.org id=B67246.17016010226360
          (code B ref 67246); Sun, 03 Dec 2023 10:58:02 +0000
Received: (at 67246) by debbugs.gnu.org; 3 Dec 2023 10:57:02 +0000
Received: from localhost ([127.0.0.1]:59172 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1r9k9l-0001eM-RJ
	for submit <at> debbugs.gnu.org; Sun, 03 Dec 2023 05:57:02 -0500
Received: from mail-ej1-x633.google.com ([2a00:1450:4864:20::633]:46281)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <andreyorst@HIDDEN>) id 1r9k9j-0001dx-Il
 for 67246 <at> debbugs.gnu.org; Sun, 03 Dec 2023 05:57:00 -0500
Received: by mail-ej1-x633.google.com with SMTP id
 a640c23a62f3a-a1b68ae40ffso25960766b.0
 for <67246 <at> debbugs.gnu.org>; Sun, 03 Dec 2023 02:56:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1701601004; x=1702205804; darn=debbugs.gnu.org;
 h=content-transfer-encoding:mime-version:message-id:in-reply-to:date
 :subject:cc:to:from:user-agent:references:from:to:cc:subject:date
 :message-id:reply-to;
 bh=WLtrCY819MIovEcX+bpWbAHq9kaW/RZ/GVYGEHbo/RQ=;
 b=A+6x9NBlS1GgdSeHCJ61m5C7Klp9bsLlJltvyD0kK1ETfXfoYM0KGMgN3Thcr0PFIX
 B890kyHdsG8WUASSmOw5J08Iv1XQ0P0xHXj8vfEDiu867HkgJLirQhoXg2axzNHVAfdt
 IYtD0LE4qkwk88scjpRyLesYpIPei4E8pTK7Rm07l6cgRXvQ0Bo/BFyWY9aTOBS1yaSP
 pfpp3ffVneE0sEntp+wjxQXSNe6xbRh5B9g31DKqd49wA1NWoexPbRkI2JfV8ZqJ8o5n
 BXqDTHRIg22YqR/yFibg2GKnO0QfvlssOPRhKys32gdfL976RvJ/VTxnsiX+OpdmSAV8
 YjHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1701601004; x=1702205804;
 h=content-transfer-encoding:mime-version:message-id:in-reply-to:date
 :subject:cc:to:from:user-agent:references:x-gm-message-state:from:to
 :cc:subject:date:message-id:reply-to;
 bh=WLtrCY819MIovEcX+bpWbAHq9kaW/RZ/GVYGEHbo/RQ=;
 b=M8rwUn9f5n3OvEKYXMJvXn/+SUFTi4K1QP+EgKWeAkstiPM0x4Q+3hgACqoXZK8b/p
 g2Uwl0qaycoFnNka0GXtHcsf6jZ3YxkPFg5uLm+HVCgHQjocyl/H+j/ZgoVGtaBQj0/F
 aiaYUki7DauIGYq7ZyFqIZJGP/ZR/VGBxGFtu1qKamw0TJbG5BXAVjKwe4+f33hbaV3P
 3bzFUo8XbkYg1WEv1JHs2IrXkMG9eusikY/av7tPceX5tNRn5rtYL7PSJw9NIIVh91gm
 D/i4qqYxKQKNcmM45u/Y6vohJ55PuteO/1fuT5lTYIVHVqrQ4qo7s+LQTKc5fCrGr0zN
 X6RQ==
X-Gm-Message-State: AOJu0YzwSVXq7NITX4Pgv2bZUHYLoBv4XqCJSxH23Sms7RwFkPJFXqtt
 vjSdzWonDcdA9/MLIvMS0kVvqe49Se4=
X-Google-Smtp-Source: AGHT+IECVOZ40WqYfsU3T+7LqgNxjbfrhVX/z32shUWRiP2LGDL094Mrxx5DvDvSqah448Cxf1LbgA==
X-Received: by 2002:a17:906:209e:b0:a08:17de:6409 with SMTP id
 30-20020a170906209e00b00a0817de6409mr1630103ejq.7.1701601003525; 
 Sun, 03 Dec 2023 02:56:43 -0800 (PST)
Received: from toolbox.smtp.gmail.com
 (broadband-46-242-11-135.ip.moscow.rt.ru. [46.242.11.135])
 by smtp.gmail.com with ESMTPSA id
 z21-20020a170906715500b009fdaab907fbsm4022397ejj.188.2023.12.03.02.56.42
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sun, 03 Dec 2023 02:56:43 -0800 (PST)
References: <87y1ewgnn7.fsf@HIDDEN>
 <e54987bb-5d2a-36b2-9ee3-fc4e3832f06c@HIDDEN>
 <CAOS0-34j_6=QYEVokunwM89F_v7xieWjpnkvGf_-yhBa+yj9Yw@HIDDEN>
 <c0ca3975-2930-dbcd-ac44-03d511309b8e@HIDDEN>
 <CAOS0-34r3DSEWN2cGGQHdvn71z-T1=bV9WCWmd322HxesdwLHQ@HIDDEN>
 <9ae8eb33-fd8b-f8d6-dd7f-79f8d4464a51@HIDDEN>
 <87a5r2p4pq.fsf@HIDDEN>
 <d3233eeb-2afc-b9fb-c7a7-4c5d5aa764c9@HIDDEN>
 <87bkbfkr1h.fsf@HIDDEN>
 <22ea1559-f44e-933d-e60a-9caa62b376a8@HIDDEN>
User-agent: mu4e 1.8.11; emacs 30.0.50
From: Andrey Listopadov <andreyorst@HIDDEN>
Date: Sun, 03 Dec 2023 13:41:20 +0300
In-reply-to: <22ea1559-f44e-933d-e60a-9caa62b376a8@HIDDEN>
Message-ID: <871qc3imfq.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


Dmitry Gutov <dmitry@HIDDEN> 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.=C2=A0 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

X-Loop: help-debbugs@HIDDEN
Subject: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Resent-From: Wilhelm Kirschbaum <wkirschbaum@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 04 Dec 2023 17:51:01 +0000
Resent-Message-ID: <handler.67246.B67246.170171220921474 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 67246
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dmitry@HIDDEN>
Cc: Andrey Listopadov <andreyorst@HIDDEN>, 67246 <at> debbugs.gnu.org
Received: via spool by 67246-submit <at> debbugs.gnu.org id=B67246.170171220921474
          (code B ref 67246); Mon, 04 Dec 2023 17:51:01 +0000
Received: (at 67246) by debbugs.gnu.org; 4 Dec 2023 17:50:09 +0000
Received: from localhost ([127.0.0.1]:35632 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1rAD56-0005aH-MN
	for submit <at> debbugs.gnu.org; Mon, 04 Dec 2023 12:50:09 -0500
Received: from mail-wm1-x329.google.com ([2a00:1450:4864:20::329]:52260)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <wkirschbaum@HIDDEN>) id 1rAD54-0005Zl-Nr
 for 67246 <at> debbugs.gnu.org; Mon, 04 Dec 2023 12:50:07 -0500
Received: by mail-wm1-x329.google.com with SMTP id
 5b1f17b1804b1-40c09dfd82aso19360475e9.0
 for <67246 <at> debbugs.gnu.org>; Mon, 04 Dec 2023 09:49:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1701712189; x=1702316989; darn=debbugs.gnu.org;
 h=content-transfer-encoding:mime-version:message-id:in-reply-to:date
 :subject:cc:to:from:user-agent:references:from:to:cc:subject:date
 :message-id:reply-to;
 bh=kNoFiV6YCgxeHB4IYzNd+jekRc4g2dnEUAWeHxGViHI=;
 b=gVMGsKAPMVm+qOHWWXK2JKqxm7Pw59YT06m0q7qAeIPybcg3qnXfDIxAo2p36soCbT
 bux0tmGW8Mp58ooRgwH4NrQI2lZ1qtuMVQ/5HYkE11P4hulVqkzxvmwIenF9S0gx1M3p
 KQk3thj1mwWX1DawILdOdWIaNPCky71jIRoj39K33WS9MmKqA3Ck8CE1hQkc13AYUTd3
 UxF9xKXwMxRJa4FbO9uM+pVB9Jcvxk5gzEnRZCPePttKYxiBpwBBx53x3WSZvL+4sh5k
 nKl1F54/wcj1b2yEwKJNOExxrViLvQbwp7SkYKsZTjIkZa25AQPc4CC1UJzqK2g6GcRZ
 6h5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1701712189; x=1702316989;
 h=content-transfer-encoding:mime-version:message-id:in-reply-to:date
 :subject:cc:to:from:user-agent:references:x-gm-message-state:from:to
 :cc:subject:date:message-id:reply-to;
 bh=kNoFiV6YCgxeHB4IYzNd+jekRc4g2dnEUAWeHxGViHI=;
 b=oQcdELDPaprYOQumaqPhw8Xf2OV6dyMbKo7zyD+y0SZYg/tYPytm7ouvljp7Fdo4uo
 IfQrcXAdFPdVc93ntTkCMryhu1KaUdwuhZ72SJRfrAkMtAt9bvRtCIjKbdsiFXdaYxVK
 5h+8kAEVQi2E2YR5SVe3Zg1H8KzAtLzXA0oIBwdwTzRxOsvsVaoJQBE8Tbg2Y8MTxnoL
 5S7gqbi/zzngwgNfC2La0kZH3yXT99tlxy/G7z2goXWP9bLjVqLqsDfHgJhZh0RaNzq0
 +C/2vrUQKkYOADQaqxx4AgmkQybRIyFdZj8RvGNrA80EhlSPugMMSqz9MZm4i+YNEAUD
 o1Iw==
X-Gm-Message-State: AOJu0YwtL5JoxvxJkvy6Z5qmSvAGCDOsDXq4LKY7xyrZ3n0uWXdlPK6x
 Fcln5IMxVpwmfeubJXTK5X7e72uiJz8=
X-Google-Smtp-Source: AGHT+IFR5CnDGderbSpMZta16wYpYVK8Khy7J7O7uAgl/CbeLZK1B64RC1YJiJeQI91zD148TlLbWg==
X-Received: by 2002:a1c:7214:0:b0:40b:5e1d:83a9 with SMTP id
 n20-20020a1c7214000000b0040b5e1d83a9mr1235801wmc.61.1701712189314; 
 Mon, 04 Dec 2023 09:49:49 -0800 (PST)
Received: from melissa.local
 (ec2-13-245-110-27.af-south-1.compute.amazonaws.com. [13.245.110.27])
 by smtp.gmail.com with ESMTPSA id
 a13-20020a05600c348d00b0040b5377cf03sm19616872wmq.1.2023.12.04.09.49.47
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 04 Dec 2023 09:49:48 -0800 (PST)
References: <87y1ewgnn7.fsf@HIDDEN>
 <e54987bb-5d2a-36b2-9ee3-fc4e3832f06c@HIDDEN>
 <CAOS0-34j_6=QYEVokunwM89F_v7xieWjpnkvGf_-yhBa+yj9Yw@HIDDEN>
 <c0ca3975-2930-dbcd-ac44-03d511309b8e@HIDDEN>
 <CAOS0-34r3DSEWN2cGGQHdvn71z-T1=bV9WCWmd322HxesdwLHQ@HIDDEN>
 <9ae8eb33-fd8b-f8d6-dd7f-79f8d4464a51@HIDDEN>
 <87a5r2p4pq.fsf@HIDDEN>
 <d3233eeb-2afc-b9fb-c7a7-4c5d5aa764c9@HIDDEN>
 <87bkbfkr1h.fsf@HIDDEN>
 <22ea1559-f44e-933d-e60a-9caa62b376a8@HIDDEN>
User-agent: mu4e 1.9.3; emacs 30.0.50
From: Wilhelm Kirschbaum <wkirschbaum@HIDDEN>
Date: Mon, 04 Dec 2023 19:46:37 +0200
In-reply-to: <22ea1559-f44e-933d-e60a-9caa62b376a8@HIDDEN>
Message-ID: <878r69vow6.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


Dmitry Gutov <dmitry@HIDDEN> writes:

> On 27/11/2023 19:59, Wilhelm Kirschbaum wrote:
>> Here is a patch to address numerous issues flagged on Elixir=20
>> slack,
>> Github and in this thread.=C2=A0 It will not be perfect, but since=20
>> the
>> changes are pretty large I want to get this in and then we can=20
>> 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=20
coming.

>> I am making the assumption that it is okay to rename custom=20
>> 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=20
>> works
>> relatively well, which means a bit more brute forcing queries.=C2=A0=20
>> I have
>> not seen a major performance issue on massic Elixir files, so=20
>> 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=20
> because the
> grammar parses these as nodes of type "call", just like it does=20
> 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" =3D> %{"line" =3D> line, "character" =3D> start_idx},
>     "end" =3D> %{"line" =3D> line, "character" =3D> start_idx +=20
>     length}
>   }
>
> are highlighted with -name-, even though there's no=20
> destructuring here.
>
> Anyway, good job, I can see that Elixir's grammar is one of the=20
> harder
> ones to work with.

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

Wilhelm

X-Loop: help-debbugs@HIDDEN
Subject: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Resent-From: Wilhelm Kirschbaum <wkirschbaum@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 04 Dec 2023 17:57:02 +0000
Resent-Message-ID: <handler.67246.B67246.170171256422049 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 67246
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Andrey Listopadov <andreyorst@HIDDEN>
Cc: 67246 <at> debbugs.gnu.org, Dmitry Gutov <dmitry@HIDDEN>
Received: via spool by 67246-submit <at> debbugs.gnu.org id=B67246.170171256422049
          (code B ref 67246); Mon, 04 Dec 2023 17:57:02 +0000
Received: (at 67246) by debbugs.gnu.org; 4 Dec 2023 17:56:04 +0000
Received: from localhost ([127.0.0.1]:35636 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1rADAp-0005jZ-Hq
	for submit <at> debbugs.gnu.org; Mon, 04 Dec 2023 12:56:03 -0500
Received: from mail-wm1-x32a.google.com ([2a00:1450:4864:20::32a]:49466)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <wkirschbaum@HIDDEN>) id 1rADAn-0005j5-OK
 for 67246 <at> debbugs.gnu.org; Mon, 04 Dec 2023 12:56:02 -0500
Received: by mail-wm1-x32a.google.com with SMTP id
 5b1f17b1804b1-40c07ed92fdso18940775e9.3
 for <67246 <at> debbugs.gnu.org>; Mon, 04 Dec 2023 09:55:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1701712545; x=1702317345; darn=debbugs.gnu.org;
 h=content-transfer-encoding:mime-version:message-id:in-reply-to:date
 :subject:cc:to:from:user-agent:references:from:to:cc:subject:date
 :message-id:reply-to;
 bh=E66K13Obp64EMNvjLp5/IzDU8dn87TrzGRXTKYsoIPY=;
 b=F1Wf4n3S+eDD7rzKXzItDMJJ4mLUfrAUZrE1oaHW7yp2kqVrNLokAaviNCJ5QxesRs
 PKVj1kfvlPPYk6lXjH6hMv25CR3brm3hAZkdJQ+TdihkbtmWnS/3/ZS95e7tFhJ7OfAD
 exisOWUYOcHQp/97WBS65fiAUl0mZSZYxFa/hgK+Ga9dFYRvChYJFvj+LlPLGXIsGQei
 /s8wgr3coy6dxTB3fQboHAwRqHCLjfU9R7rNhCPoh5OsQNT80jh4hAEfrzN+GDxae3wn
 MtAhv200cJu3VolMIpzY1eHO5BFDxsjwh6AI7wKs7Mio0+9MopEELVflokJrTiFAn4j1
 WOsQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1701712545; x=1702317345;
 h=content-transfer-encoding:mime-version:message-id:in-reply-to:date
 :subject:cc:to:from:user-agent:references:x-gm-message-state:from:to
 :cc:subject:date:message-id:reply-to;
 bh=E66K13Obp64EMNvjLp5/IzDU8dn87TrzGRXTKYsoIPY=;
 b=Ge50V1wMTTOi9oXkwmm0Mx801wpeoqA3fVikB6qGojVua11vL5iQ3s4uk6kaslEWIJ
 7eWCSE7SL781liTOfPPc/jDL1Xj3o5G4Tpgny/LtIl/DelBWtNUPvcVa9J7pWq0bPGop
 LkWwmlNyiq/S3D6tHeFSQk2QDM8BzCS/MF140y/iMIF1n+Meb38AuhJmb5SBv61IZ7DZ
 lbpvxaZ2hqC8cFm5C97Hxy+DrxeynPAMiMqi1BR7fOr7us07ZZZgy38O966HDr9T2SxC
 IY8LGIIARJP2A6wEn8h+YEVdbyBaw9BdXL2YJk+UhzGt3XuW0Eu7tnqYxD7U0M81bPe1
 Yi3g==
X-Gm-Message-State: AOJu0YznGE2tfwuz9ZGerzlumImtkBBgXBGjOUpnVO5nBifcmNyoMCC+
 GdpOEbtPfRsf0nKG9+vFJ+E5IOBgFog=
X-Google-Smtp-Source: AGHT+IFIacKHs5NQZiw8pIBW8gbwoVLUPaj78OOwTc2ZuwWqEpZ1oSya051HaL4dmOClEdDnco3q5Q==
X-Received: by 2002:a05:600c:1994:b0:406:c6de:2bea with SMTP id
 t20-20020a05600c199400b00406c6de2beamr2435593wmq.17.1701712544766; 
 Mon, 04 Dec 2023 09:55:44 -0800 (PST)
Received: from melissa.local
 (ec2-13-245-110-27.af-south-1.compute.amazonaws.com. [13.245.110.27])
 by smtp.gmail.com with ESMTPSA id
 c8-20020adfe708000000b003332aa97101sm11261787wrm.38.2023.12.04.09.55.43
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 04 Dec 2023 09:55:44 -0800 (PST)
References: <87y1ewgnn7.fsf@HIDDEN>
 <e54987bb-5d2a-36b2-9ee3-fc4e3832f06c@HIDDEN>
 <CAOS0-34j_6=QYEVokunwM89F_v7xieWjpnkvGf_-yhBa+yj9Yw@HIDDEN>
 <c0ca3975-2930-dbcd-ac44-03d511309b8e@HIDDEN>
 <CAOS0-34r3DSEWN2cGGQHdvn71z-T1=bV9WCWmd322HxesdwLHQ@HIDDEN>
 <9ae8eb33-fd8b-f8d6-dd7f-79f8d4464a51@HIDDEN>
 <87a5r2p4pq.fsf@HIDDEN>
 <d3233eeb-2afc-b9fb-c7a7-4c5d5aa764c9@HIDDEN>
 <87bkbfkr1h.fsf@HIDDEN>
 <22ea1559-f44e-933d-e60a-9caa62b376a8@HIDDEN>
 <871qc3imfq.fsf@HIDDEN>
User-agent: mu4e 1.9.3; emacs 30.0.50
From: Wilhelm Kirschbaum <wkirschbaum@HIDDEN>
Date: Mon, 04 Dec 2023 19:50:06 +0200
In-reply-to: <871qc3imfq.fsf@HIDDEN>
Message-ID: <874jgxvoma.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


Andrey Listopadov <andreyorst@HIDDEN> writes:

> Dmitry Gutov <dmitry@HIDDEN> writes:
>
>> On 27/11/2023 19:59, Wilhelm Kirschbaum wrote:
>>> Here is a patch to address numerous issues flagged on Elixir=20
>>> slack,
>>> Github and in this thread.=C2=A0 It will not be perfect, but since=20
>>> the
>>> changes are pretty large I want to get this in and then we can=20
>>> 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=20
> tested
> the update and noticed that putting the `do' keyword on a=20
> 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=20
> first
> `do' keyword (case A), but the matching `end' keyword was=20
> indented
> automatically when I called `indent-region' on the whole buffer.=20
> The
> case B seems to be indented incorrectly, the default formatter=20
> would
> indent such `do:' by just two spaces after the parent `defp'.
>
> The third case C is similar to case A, except the indentation=20
> was
> provided by Emacs, meaning, after pressing the RET key before=20
> the `do'
> keyword, Emacs had put the keyword at the BOL. If there are no=20
> `do'
> after the closing parenthesis, the automatic indentation is=20
> correct.
>
> I'm not sure if these problems were introduced by the changes,=20
> or were
> present before, and if I should send a separeate bug report for=20
> 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=20
thread
would not impact indentation.

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

Wilhelm

X-Loop: help-debbugs@HIDDEN
Subject: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Resent-From: Stefan Kangas <stefankangas@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 10 Jan 2024 17:49:02 +0000
Resent-Message-ID: <handler.67246.B67246.170490888610153 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 67246
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Wilhelm Kirschbaum <wkirschbaum@HIDDEN>
Cc: Andrey Listopadov <andreyorst@HIDDEN>, Dmitry Gutov <dmitry@HIDDEN>, 67246 <at> debbugs.gnu.org
Received: via spool by 67246-submit <at> debbugs.gnu.org id=B67246.170490888610153
          (code B ref 67246); Wed, 10 Jan 2024 17:49:02 +0000
Received: (at 67246) by debbugs.gnu.org; 10 Jan 2024 17:48:06 +0000
Received: from localhost ([127.0.0.1]:42881 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1rNcgQ-0002dg-8N
	for submit <at> debbugs.gnu.org; Wed, 10 Jan 2024 12:48:06 -0500
Received: from mail-ed1-x52a.google.com ([2a00:1450:4864:20::52a]:59729)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <stefankangas@HIDDEN>) id 1rNcgO-0002cK-Hu
 for 67246 <at> debbugs.gnu.org; Wed, 10 Jan 2024 12:48:04 -0500
Received: by mail-ed1-x52a.google.com with SMTP id
 4fb4d7f45d1cf-554fe147ddeso5204140a12.3
 for <67246 <at> debbugs.gnu.org>; Wed, 10 Jan 2024 09:48:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1704908880; x=1705513680; darn=debbugs.gnu.org;
 h=cc:to:subject:message-id:date:mime-version:references:in-reply-to
 :from:from:to:cc:subject:date:message-id:reply-to;
 bh=xIZnqlxp9jseUO/vMCjPOqoPES5OOQNdug2pTzffiHs=;
 b=FTbhuoPPmMMgGyBarZYA86Ww1PggEDid2a/AmY1hULB5vmue2fxR1nEkvSTMU9CWqc
 pOg7weAFyj4mI6nCRv5bCv6ZY+LH93+MPFWooMvyYKDE2OWJltOgjgft/dTZiu/YCq5c
 MpzSudQ8xZuusQGjfzbmTX4gwkb/SJ9vLd8ccZmvcqMfrNe0eep552GBvPla9Hc6AwKR
 FDPKCb/Y/BVWgRmfTXfRSB8+W9/qHvmoTqbXfMVoNk1O9PhyoPfpyukMspOYH+Gyp8f4
 HO7TCkWfAlZBeerJEvlg+s11y2Bm/9cQwJCvIm1NrLMEqqJMAW9XF/ghQXldSlQRWdZ5
 zzMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1704908880; x=1705513680;
 h=cc:to:subject:message-id:date:mime-version:references:in-reply-to
 :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=xIZnqlxp9jseUO/vMCjPOqoPES5OOQNdug2pTzffiHs=;
 b=lPBF7nmkd8wYXoQTPmOBGri3p5a+tr2OSnihJ0dbqsIAxvjTrlU8lCdi8PxaX4F4iP
 TFDRPljb55Ohc2x6IQ5PTKdtvbYWH9hfQuZ5vdglLJC5r8MPKNnlT5z028wsCdrhJbAW
 eMspkyC7MIeAK01dDzI47yrcRdyAMaNyHCGcKvbde/8zse8eg6dZ4PZ+h2kkEWD5R66b
 ad6hOJCIui16KGYFKDbLwtMbm99lmf02+rNTceToF0XjAZNsedvYKEzmqrzuN5gPKyBF
 jleqHTfer9dPF8PH4ATAqtLunw+ypgIlPoDlEO5whyESC2IR/sLFg1kBCgE2HtXNgSmr
 FkAg==
X-Gm-Message-State: AOJu0YyfuMEwwPj7PzVqQ3HY8zp4coxJYNNnUz9lBmJ4lxfXSqmguz2A
 bg/dJY6zQl/prELdgz3F6QCOcFm2Ukobsx0hY46aM/iYxhOxAQ==
X-Google-Smtp-Source: AGHT+IG3rbknfn3m3521stQSkiDOkn1AuVj1RZdW7vXmHr2D+NLk/mizhIxT6yoZxgce/vlhNvRPGai4v2nFyYUaMfE=
X-Received: by 2002:a50:9fa1:0:b0:557:ca5e:6ea3 with SMTP id
 c30-20020a509fa1000000b00557ca5e6ea3mr275104edf.81.1704908880112; Wed, 10 Jan
 2024 09:48:00 -0800 (PST)
Received: from 753933720722 named unknown by gmailapi.google.com with
 HTTPREST; Wed, 10 Jan 2024 09:47:59 -0800
From: Stefan Kangas <stefankangas@HIDDEN>
In-Reply-To: <878r69vow6.fsf@HIDDEN> (Wilhelm Kirschbaum's message of "Mon, 
 04 Dec 2023 19:46:37 +0200")
References: <87y1ewgnn7.fsf@HIDDEN>
 <e54987bb-5d2a-36b2-9ee3-fc4e3832f06c@HIDDEN>
 <CAOS0-34j_6=QYEVokunwM89F_v7xieWjpnkvGf_-yhBa+yj9Yw@HIDDEN>
 <c0ca3975-2930-dbcd-ac44-03d511309b8e@HIDDEN>
 <CAOS0-34r3DSEWN2cGGQHdvn71z-T1=bV9WCWmd322HxesdwLHQ@HIDDEN>
 <9ae8eb33-fd8b-f8d6-dd7f-79f8d4464a51@HIDDEN> <87a5r2p4pq.fsf@HIDDEN>
 <d3233eeb-2afc-b9fb-c7a7-4c5d5aa764c9@HIDDEN> <87bkbfkr1h.fsf@HIDDEN>
 <22ea1559-f44e-933d-e60a-9caa62b376a8@HIDDEN> <878r69vow6.fsf@HIDDEN>
MIME-Version: 1.0
Date: Wed, 10 Jan 2024 09:47:59 -0800
Message-ID: <CADwFkmmo4QvGEVNvw1jM4otLwg+Gz_Jw7Vr8SfMsRWDLGcOAAw@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Wilhelm Kirschbaum <wkirschbaum@HIDDEN> writes:

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

Any updates here?

X-Loop: help-debbugs@HIDDEN
Subject: bug#67246: 30.0.50; elixir-ts-mode uses faces inconsistently
Resent-From: Wilhelm Kirschbaum <wkirschbaum@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 13 Jan 2024 08:51:01 +0000
Resent-Message-ID: <handler.67246.B67246.170513584228372 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 67246
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Kangas <stefankangas@HIDDEN>
Cc: Andrey Listopadov <andreyorst@HIDDEN>, Dmitry Gutov <dmitry@HIDDEN>, 67246 <at> debbugs.gnu.org
Received: via spool by 67246-submit <at> debbugs.gnu.org id=B67246.170513584228372
          (code B ref 67246); Sat, 13 Jan 2024 08:51:01 +0000
Received: (at 67246) by debbugs.gnu.org; 13 Jan 2024 08:50:42 +0000
Received: from localhost ([127.0.0.1]:38360 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1rOZiz-0007NY-VI
	for submit <at> debbugs.gnu.org; Sat, 13 Jan 2024 03:50:42 -0500
Received: from mail-qt1-x831.google.com ([2607:f8b0:4864:20::831]:57478)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <wkirschbaum@HIDDEN>) id 1rOZiw-0007NI-UH
 for 67246 <at> debbugs.gnu.org; Sat, 13 Jan 2024 03:50:40 -0500
Received: by mail-qt1-x831.google.com with SMTP id
 d75a77b69052e-429de32dad9so990001cf.2
 for <67246 <at> debbugs.gnu.org>; Sat, 13 Jan 2024 00:50:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1705135835; x=1705740635; darn=debbugs.gnu.org;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=jTrJvZg13rLgTSQ0TZHLZqDvvHP5Wqhg7mmL2Dsa3o0=;
 b=SVJb0ZzlNo6qsJgzvvbfTr6oTLPoQeIRLMn6adrzckgMdprpfsBgbRvr24Cf/NB5Ym
 SfSF8EwtpJo+9Opo1nnYexLDE+SvgohYlEICrEmM8exrg3H99dSRPVEk9s3f57r3xnAt
 iqUCCgMuT8RU6N76WFXPjgUz7v+z3Sb54fwy0C8JL/9x0Baorql5Qfe6fpFHnXMww7AW
 oB+B9FnrCAghobGhMc8wJ7fNNNISP3+HLlQOqnR0H2dp9vkKHeTXDWVHvPxabvFGd40D
 XnOqF3r9HEqDajGbrU0CAugkHN1ziz8QGLlzpzFFMR3zeNTfzb5Yh3mL66jkJIzVE9ol
 2URQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1705135835; x=1705740635;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=jTrJvZg13rLgTSQ0TZHLZqDvvHP5Wqhg7mmL2Dsa3o0=;
 b=bRzBhmh82FvTTNokCJRWgmG+UNkoAhCFnH6dIHDd8Ukt+Wok/qXECEYe7N1XSZWHAk
 Q9ibuO3C5W+yNj+M5dK40QOS5d5qYbKJeODoktVsK+zgyaN5DpQd5uwKZkkwV5oukA2K
 opTG05+CPqj7yXppQwcxu+Ot3NKGtWH11N0s/cb79ybR6s8/0oYzkV+IxKyP9VqJAhup
 ZlVU17NZ8Y65aRZr1T2GjdQe7QDv0HFgaARoTrPr5pLvYvroCyDRjwL3e0zLn4m0dwmd
 8xxrkESYFHrBxpkEzIOKoetCqPjKDvLkZjfvx5XvQcYv1SQqYr/Pq3/zPoiWA/gXQ+2N
 WEoA==
X-Gm-Message-State: AOJu0YyIO+RyMuuaLNPROG5IgrVO3XQpSNAkDqoTmXAdt8KM13YlkKW+
 h5GJVxNd0YOHJWzbPebSg3OydAd+OEp5addJ9Gw=
X-Google-Smtp-Source: AGHT+IEJmrZUV4HYRs6EjvLdYjcXCVvJ0eWfUiV45MIbB+0woI4Jf/zkcbVQsRfo2xibk0PF/xO+3HhomRYjA1skSq0=
X-Received: by 2002:ac8:5703:0:b0:429:c0d3:914b with SMTP id
 3-20020ac85703000000b00429c0d3914bmr3170969qtw.113.1705135834735; Sat, 13 Jan
 2024 00:50:34 -0800 (PST)
MIME-Version: 1.0
References: <87y1ewgnn7.fsf@HIDDEN>
 <e54987bb-5d2a-36b2-9ee3-fc4e3832f06c@HIDDEN>
 <CAOS0-34j_6=QYEVokunwM89F_v7xieWjpnkvGf_-yhBa+yj9Yw@HIDDEN>
 <c0ca3975-2930-dbcd-ac44-03d511309b8e@HIDDEN>
 <CAOS0-34r3DSEWN2cGGQHdvn71z-T1=bV9WCWmd322HxesdwLHQ@HIDDEN>
 <9ae8eb33-fd8b-f8d6-dd7f-79f8d4464a51@HIDDEN> <87a5r2p4pq.fsf@HIDDEN>
 <d3233eeb-2afc-b9fb-c7a7-4c5d5aa764c9@HIDDEN> <87bkbfkr1h.fsf@HIDDEN>
 <22ea1559-f44e-933d-e60a-9caa62b376a8@HIDDEN> <878r69vow6.fsf@HIDDEN>
 <CADwFkmmo4QvGEVNvw1jM4otLwg+Gz_Jw7Vr8SfMsRWDLGcOAAw@HIDDEN>
In-Reply-To: <CADwFkmmo4QvGEVNvw1jM4otLwg+Gz_Jw7Vr8SfMsRWDLGcOAAw@HIDDEN>
From: Wilhelm Kirschbaum <wkirschbaum@HIDDEN>
Date: Sat, 13 Jan 2024 10:50:23 +0200
Message-ID: <CAOS0-347naY2EUHYBNo57duVwuDY73ryCoiAdMTvWDWmeojiOw@HIDDEN>
Content-Type: multipart/mixed; boundary="000000000000b94e3e060ecfdfcf"
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--000000000000b94e3e060ecfdfcf
Content-Type: multipart/alternative; boundary="000000000000b94e3c060ecfdfcd"

--000000000000b94e3c060ecfdfcd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Jan 10, 2024 at 7:48=E2=80=AFPM Stefan Kangas <stefankangas@HIDDEN=
om>
wrote:

> Wilhelm Kirschbaum <wkirschbaum@HIDDEN> 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

--000000000000b94e3c060ecfdfcd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Wed, Jan 10, 2024 at 7:48=E2=80=AFPM S=
tefan Kangas &lt;<a href=3D"mailto:stefankangas@HIDDEN">stefankangas@gma=
il.com</a>&gt; wrote:</div><div class=3D"gmail_quote"><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex">Wilhelm Kirschbaum &lt;<a href=3D"mailto:wkirs=
chbaum@HIDDEN" target=3D"_blank">wkirschbaum@HIDDEN</a>&gt; writes:<b=
r>
<br>
&gt; Thanks, I have one or two more change related to this issue coming.<br=
>
<br>
Any updates here?<br></blockquote><div><br></div><div>This patch is the las=
t 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&#39=
;t think they need to be part of this issue.=C2=A0</div><div><br></div><div=
>Wilhelm <br></div></div></div>

--000000000000b94e3c060ecfdfcd--

--000000000000b94e3e060ecfdfcf
Content-Type: text/x-patch; charset="US-ASCII"; 
	name="0001-Add-access_call-fontification-to-elixir-ts-mode.patch"
Content-Disposition: attachment; 
	filename="0001-Add-access_call-fontification-to-elixir-ts-mode.patch"
Content-Transfer-Encoding: base64
Content-ID: <f_lrbtty9s0>
X-Attachment-Id: f_lrbtty9s0

RnJvbSAzODQ1ZDg2OTIxMTA2OWYzMzYxYzllMDIwNzdjNjBlY2VmYjcxMTBhIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBXaWxoZWxtIEtpcnNjaGJhdW0gPHdraXJzY2hiYXVtQGdtYWls
LmNvbT4KRGF0ZTogRnJpLCAyOSBEZWMgMjAyMyAxNzowOTowMCArMDIwMApTdWJqZWN0OiBbUEFU
Q0hdIEFkZCBhY2Nlc3NfY2FsbCBmb250aWZpY2F0aW9uIHRvIGVsaXhpci10cy1tb2RlCgoqIGxp
c3AvcHJvZ21vZGVzL2VsaXhpci10cy1tb2RlLmVsOgooZWxpeGlyLXRzLS1mb250LWxvY2stc2V0
dGluZ3MpOgpBZGQgYWNjZXNzX2NhbGwgcXVlcmllcyB0byB0aGUgZWxpeGlyLXZhcmlhYmxlIGZl
YXR1cmUuCi0tLQogbGlzcC9wcm9nbW9kZXMvZWxpeGlyLXRzLW1vZGUuZWwgfCA0ICsrKy0KIDEg
ZmlsZSBjaGFuZ2VkLCAzIGluc2VydGlvbnMoKyksIDEgZGVsZXRpb24oLSkKCmRpZmYgLS1naXQg
YS9saXNwL3Byb2dtb2Rlcy9lbGl4aXItdHMtbW9kZS5lbCBiL2xpc3AvcHJvZ21vZGVzL2VsaXhp
ci10cy1tb2RlLmVsCmluZGV4IGI0OTMxOTVlZWRkLi4yYzczMjNjMzE4ZCAxMDA2NDQKLS0tIGEv
bGlzcC9wcm9nbW9kZXMvZWxpeGlyLXRzLW1vZGUuZWwKKysrIGIvbGlzcC9wcm9nbW9kZXMvZWxp
eGlyLXRzLW1vZGUuZWwKQEAgLTU0Niw3ICs1NDYsOSBAQCBlbGl4aXItdHMtLWZvbnQtbG9jay1z
ZXR0aW5ncwogICAgICAoYm9keSAoaWRlbnRpZmllcikgQGZvbnQtbG9jay12YXJpYWJsZS1uYW1l
LWZhY2UpCiAgICAgICh1bmFyeV9vcGVyYXRvciBvcGVyYW5kOiAoaWRlbnRpZmllcikgQGZvbnQt
bG9jay12YXJpYWJsZS1uYW1lLWZhY2UpCiAgICAgIChpbnRlcnBvbGF0aW9uIChpZGVudGlmaWVy
KSBAZm9udC1sb2NrLXZhcmlhYmxlLW5hbWUtZmFjZSkKLSAgICAgKGRvX2Jsb2NrIChpZGVudGlm
aWVyKSBAZm9udC1sb2NrLXZhcmlhYmxlLW5hbWUtZmFjZSkpCisgICAgIChkb19ibG9jayAoaWRl
bnRpZmllcikgQGZvbnQtbG9jay12YXJpYWJsZS1uYW1lLWZhY2UpCisgICAgIChhY2Nlc3NfY2Fs
bCB0YXJnZXQ6IChpZGVudGlmaWVyKSBAZm9udC1sb2NrLXZhcmlhYmxlLW5hbWUtZmFjZSkKKyAg
ICAgKGFjY2Vzc19jYWxsICJbIiBrZXk6IChpZGVudGlmaWVyKSBAZm9udC1sb2NrLXZhcmlhYmxl
LW5hbWUtZmFjZSAiXSIpKQogCiAgICA6bGFuZ3VhZ2UgJ2VsaXhpcgogICAgOmZlYXR1cmUgJ2Vs
aXhpci1idWlsdGluCi0tIAoyLjM0LjEKCg==
--000000000000b94e3e060ecfdfcf--