GNU bug report logs - #79944
30.2; bash-ts-mode fontification of command invocations

Previous Next

To reply to this bug, email your comments to 79944 AT debbugs.gnu.org.
There is no need to reopen the bug first.

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

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

From: Robert Brown <robert.brown <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.2; bash-ts-mode fontification of command invocations
Date: Wed, 3 Dec 2025 15:13:07 -0500

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

With bash-ts-mode every invocation of a command in a bash script is
incorrectly fontified using face font-lock-function-name-face.  In
non-ts modes font-lock-function-name-face has historically only been
used to fontify a function name where the function is defined, not every
place where it's used.  As an example, let's say we have this bash
script:

    logout() { exit }
    who

Mode sh-mode fontifies "logout" using font-lock-function-name-face and
"who" using the default face.  Mode bash-ts-mode fontifies both "logout"
and "who" using font-lock-function-name-face.

I believe the bug is here in sh-script.el:

   :feature 'command
   :language 'bash
   `(;; function/non-builtin command calls
     (command_name (word) @font-lock-function-name-face)

The last line should be deleted.



In GNU Emacs 30.2 (build 2, x86_64-pc-linux-gnu) of 2025-11-19 built on
 chuwi
System Description: Ubuntu 24.04.3 LTS

Configured using:
 'configure --without-x
 --prefix=/home/brown/local/software/package/emacs-30.2'

Configured features:
DBUS GMP GNUTLS LIBSELINUX LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY
PDUMPER SECCOMP SOUND THREADS TREE_SITTER XIM ZLIB

Important settings:
  value of $LC_COLLATE: C
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: ELisp/l

Minor modes in effect:
  bug-reference-prog-mode: t
  company-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: t
  line-number-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
/home/brown/lib/emacs/lisp/yow hides
/home/brown/local/software/package/emacs-30.2/share/emacs/30.2/lisp/obsolete/yow

Features:
(shadow sort mail-extr warnings emacsbug message yank-media puny dired
dnd dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068 epg-config
gnus-util time-date mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils compile text-property-search comint
ansi-osc ansi-color comp-run comp-common cl-extra pp wid-edit descr-text
help-mode sh-script smie treesit executable mule-util
display-line-numbers ebuff-menu misearch multi-isearch bug-reference
thingatpt term/xterm xterm company-oddmuse company-keywords
company-etags etags fileloop generator xref project ring company-gtags
company-dabbrev-code company-dabbrev company-files company-clang
company-capf company-cmake company-semantic company-template
company-bbdb company pcase slime-autoloads cc-styles cc-align cc-engine
cc-vars cc-defs regexp-opt rx company-autoloads info tool-bar
dash-autoloads markdown-mode-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 icons 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 tabulated-list replace newcomment
text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow
isearch easymenu timer select 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 dbusbind inotify multi-tty
make-network-process native-compile emacs)

Memory information:
((conses 16 213996 409137) (symbols 48 25457 72) (strings 32 100807 16993)
 (string-bytes 1 2588670) (vectors 16 20693) (vector-slots 8 297302 169755)
 (floats 8 77 193) (intervals 56 9953 1809) (buffers 992 19))

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Robert Brown <robert.brown <at> gmail.com>,
 Jostein Kjønigsen <jostein <at> kjonigsen.net>,
 Yuan Fu <casouri <at> gmail.com>
Cc: 79944 <at> debbugs.gnu.org
Subject: Re: bug#79944: 30.2; bash-ts-mode fontification of command invocations
Date: Thu, 04 Dec 2025 08:59:15 +0200

> From: Robert Brown <robert.brown <at> gmail.com>
> Date: Wed, 3 Dec 2025 15:13:07 -0500
> 
> With bash-ts-mode every invocation of a command in a bash script is
> incorrectly fontified using face font-lock-function-name-face.  In
> non-ts modes font-lock-function-name-face has historically only been
> used to fontify a function name where the function is defined, not every
> place where it's used.  As an example, let's say we have this bash
> script:
> 
>     logout() { exit }
>     who
> 
> Mode sh-mode fontifies "logout" using font-lock-function-name-face and
> "who" using the default face.  Mode bash-ts-mode fontifies both "logout"
> and "who" using font-lock-function-name-face.
> 
> I believe the bug is here in sh-script.el:
> 
>    :feature 'command
>    :language 'bash
>    `(;; function/non-builtin command calls
>      (command_name (word) @font-lock-function-name-face)
> 
> The last line should be deleted.

Thanks.

Jostein and Yuan, WDYT?

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

From: Jostein Kjønigsen <jostein <at> secure.kjonigsen.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Yuan Fu <casouri <at> gmail.com>, Robert Brown <robert.brown <at> gmail.com>,
 Jostein Kjønigsen <jostein <at> kjonigsen.net>,
 79944 <at> debbugs.gnu.org
Subject: Re: bug#79944: 30.2; bash-ts-mode fontification of command invocations
Date: Thu, 4 Dec 2025 08:51:20 +0100

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

> On 4 Dec 2025, at 07:59, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>> From: Robert Brown <robert.brown <at> gmail.com>
>> Date: Wed, 3 Dec 2025 15:13:07 -0500
>> 
>> With bash-ts-mode every invocation of a command in a bash script is
>> incorrectly fontified using face font-lock-function-name-face.

I agree this sounds like an error.

>>  In
>> non-ts modes font-lock-function-name-face has historically only been
>> used to fontify a function name where the function is defined, not every
>> place where it's used.

;; START short philosphy preamble :) 

Tree-sitter allows us to get much more rich and accurate grammar for a buffer than we've historically been able to achieve using reg-exp and Elisp.

Based on that I don't necessarily agree that the new tree-sitter based major-modes should mimic previous Reg-exp based major-modes down to the last detail. If so, why even implement them?

What I think makes more sense is using the richer grammar which we can now get for most languages to craft a consistent editing experience in Emacs, across all languages:

- classes being declared
- functions being defined
- variables being declared
- functions being called
- variables being referenced
- properties being declared
- string templating
- variables and function-calls made inside string-templates
- etc

All those constructs can now reliably be identified across most languages, and this gives us the possibility to fontify them consistently too.

For all tree-sitter major-modes I've been contributing to (at least 7), this has been my high-level goal, as opposed to mimicking whatever existed before.

;; END preamble


>>  As an example, let's say we have this bash
>> script:
>> 
>>    logout() { exit }
>>    who
>> 
>> Mode sh-mode fontifies "logout" using font-lock-function-name-face and
>> "who" using the default face.  Mode bash-ts-mode fontifies both "logout"

I would argue that semantically "who" is a command which does something. It's a function in form of an external binary or command.

So this would semantically constitute a function call.

>> and "who" using font-lock-function-name-face.

I agree this is inappropriate and incorrect. font-lock-function-name-face should ideally only be used for function-definitions. And this is not a function definition.

>> 
>> I believe the bug is here in sh-script.el:
>> 
>>   :feature 'command
>>   :language 'bash
>>   `(;; function/non-builtin command calls
>>     (command_name (word) @font-lock-function-name-face)

That seems to be the culprit indeed.

>> 
>> The last line should be deleted.

Disagree.

I think instead changing it to font-lock-function-call-face would make it more consistent with the semantics of the other tree-sitter based major-modes we currently have in Emacs.

> 
> Thanks.
> 
> Jostein and Yuan, WDYT?

If there's no big disagreements to the design, approach and philosophy outlined above, below is a patch which implements this change :) 

[0001-sh-script-Fix-fontification-of-command-invocations-i.patch (application/octet-stream, attachment)]

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

--
Jostein

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

From: Robert Brown <robert.brown <at> gmail.com>
To: Jostein Kjønigsen <jostein <at> secure.kjonigsen.net>
Cc: 79944 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Jostein Kjønigsen <jostein <at> kjonigsen.net>,
 Yuan Fu <casouri <at> gmail.com>
Subject: Re: bug#79944: 30.2; bash-ts-mode fontification of command invocations
Date: Thu, 4 Dec 2025 22:43:48 -0500

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

The patch looks good to me.  Thanks!

I somewhat agree with the philosophical digression.  Tree sitter
fontification should be an extension of that provided by current language
modes.  I'm interested in it because it's more accurate and more
efficient.  I will configure tree sitter modes so that variable references,
function calls, and pretty much all of the other new semantic distinctions
are fontified using the default face.  My general guide is:
https://www.amazon.com/Human-Factors-Typography-Readable-Programs/dp/0201107457
The fontification provided by most IDEs these days ends up hurting
readability.


On Thu, Dec 4, 2025 at 2:51 AM Jostein Kjønigsen <
jostein <at> secure.kjonigsen.net> wrote:

> > On 4 Dec 2025, at 07:59, Eli Zaretskii <eliz <at> gnu.org> wrote:
> >
> >> From: Robert Brown <robert.brown <at> gmail.com>
> >> Date: Wed, 3 Dec 2025 15:13:07 -0500
> >>
> >> With bash-ts-mode every invocation of a command in a bash script is
> >> incorrectly fontified using face font-lock-function-name-face.
>
> I agree this sounds like an error.
>
> >>  In
> >> non-ts modes font-lock-function-name-face has historically only been
> >> used to fontify a function name where the function is defined, not every
> >> place where it's used.
>
> ;; START short philosphy preamble :)
>
> Tree-sitter allows us to get much more rich and accurate grammar for a
> buffer than we've historically been able to achieve using reg-exp and Elisp.
>
> Based on that I don't necessarily agree that the new tree-sitter based
> major-modes should mimic previous Reg-exp based major-modes down to the
> last detail. If so, why even implement them?
>
> What I think makes more sense is using the richer grammar which we can now
> get for most languages to craft a consistent editing experience in Emacs,
> across all languages:
>
> - classes being declared
> - functions being defined
> - variables being declared
> - functions being called
> - variables being referenced
> - properties being declared
> - string templating
> - variables and function-calls made inside string-templates
> - etc
>
> All those constructs can now reliably be identified across most languages,
> and this gives us the possibility to fontify them consistently too.
>
> For all tree-sitter major-modes I've been contributing to (at least 7),
> this has been my high-level goal, as opposed to mimicking whatever existed
> before.
>
> ;; END preamble
>
>
> >>  As an example, let's say we have this bash
> >> script:
> >>
> >>    logout() { exit }
> >>    who
> >>
> >> Mode sh-mode fontifies "logout" using font-lock-function-name-face and
> >> "who" using the default face.  Mode bash-ts-mode fontifies both "logout"
>
> I would argue that semantically "who" is a command which does something.
> It's a function in form of an external binary or command.
>
> So this would semantically constitute a function call.
>
> >> and "who" using font-lock-function-name-face.
>
> I agree this is inappropriate and incorrect. font-lock-function-name-face
> should ideally only be used for function-definitions. And this is not a
> function definition.
>
> >>
> >> I believe the bug is here in sh-script.el:
> >>
> >>   :feature 'command
> >>   :language 'bash
> >>   `(;; function/non-builtin command calls
> >>     (command_name (word) @font-lock-function-name-face)
>
> That seems to be the culprit indeed.
>
> >>
> >> The last line should be deleted.
>
> Disagree.
>
> I think instead changing it to font-lock-function-call-face would make it
> more consistent with the semantics of the other tree-sitter based
> major-modes we currently have in Emacs.
>
> >
> > Thanks.
> >
> > Jostein and Yuan, WDYT?
>
> If there's no big disagreements to the design, approach and philosophy
> outlined above, below is a patch which implements this change :)
>
> --
> Jostein

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

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

From: Yuan Fu <casouri <at> gmail.com>
To: Jostein Kjønigsen <jostein <at> secure.kjonigsen.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Robert Brown <robert.brown <at> gmail.com>,
 Jostein Kjønigsen <jostein <at> kjonigsen.net>,
 79944 <at> debbugs.gnu.org
Subject: Re: bug#79944: 30.2; bash-ts-mode fontification of command invocations
Date: Thu, 4 Dec 2025 22:20:02 -0800

> On Dec 3, 2025, at 11:51 PM, Jostein Kjønigsen <jostein <at> secure.kjonigsen.net> wrote:
> 
>> On 4 Dec 2025, at 07:59, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> 
>>> From: Robert Brown <robert.brown <at> gmail.com>
>>> Date: Wed, 3 Dec 2025 15:13:07 -0500
>>> 
>>> With bash-ts-mode every invocation of a command in a bash script is
>>> incorrectly fontified using face font-lock-function-name-face.
> 
> I agree this sounds like an error.
> 
>>> In
>>> non-ts modes font-lock-function-name-face has historically only been
>>> used to fontify a function name where the function is defined, not every
>>> place where it's used.
> 
> ;; START short philosphy preamble :) 
> 
> Tree-sitter allows us to get much more rich and accurate grammar for a buffer than we've historically been able to achieve using reg-exp and Elisp.
> 
> Based on that I don't necessarily agree that the new tree-sitter based major-modes should mimic previous Reg-exp based major-modes down to the last detail. If so, why even implement them?
> 
> What I think makes more sense is using the richer grammar which we can now get for most languages to craft a consistent editing experience in Emacs, across all languages:
> 
> - classes being declared
> - functions being defined
> - variables being declared
> - functions being called
> - variables being referenced
> - properties being declared
> - string templating
> - variables and function-calls made inside string-templates
> - etc
> 
> All those constructs can now reliably be identified across most languages, and this gives us the possibility to fontify them consistently too.
> 
> For all tree-sitter major-modes I've been contributing to (at least 7), this has been my high-level goal, as opposed to mimicking whatever existed before.
> 
> ;; END preamble
> 
> 
>>> As an example, let's say we have this bash
>>> script:
>>> 
>>>   logout() { exit }
>>>   who
>>> 
>>> Mode sh-mode fontifies "logout" using font-lock-function-name-face and
>>> "who" using the default face.  Mode bash-ts-mode fontifies both "logout"
> 
> I would argue that semantically "who" is a command which does something. It's a function in form of an external binary or command.
> 
> So this would semantically constitute a function call.
> 
>>> and "who" using font-lock-function-name-face.
> 
> I agree this is inappropriate and incorrect. font-lock-function-name-face should ideally only be used for function-definitions. And this is not a function definition.
> 
>>> 
>>> I believe the bug is here in sh-script.el:
>>> 
>>>  :feature 'command
>>>  :language 'bash
>>>  `(;; function/non-builtin command calls
>>>    (command_name (word) @font-lock-function-name-face)
> 
> That seems to be the culprit indeed.
> 
>>> 
>>> The last line should be deleted.
> 
> Disagree.
> 
> I think instead changing it to font-lock-function-call-face would make it more consistent with the semantics of the other tree-sitter based major-modes we currently have in Emacs.
> 
>> 
>> Thanks.
>> 
>> Jostein and Yuan, WDYT?
> 
> If there's no big disagreements to the design, approach and philosophy outlined above, below is a patch which implements this change :) 
> 
> <0001-sh-script-Fix-fontification-of-command-invocations-i.patch>—
> Jostein

I Agree. Even better would be splitting fontification into two features highlighting the definition and use separately. But that can be future work.

Yuan

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

From: Yuan Fu <casouri <at> gmail.com>
To: Robert Brown <robert.brown <at> gmail.com>
Cc: Jostein Kjønigsen <jostein <at> kjonigsen.net>,
 Eli Zaretskii <eliz <at> gnu.org>,
 Jostein Kjønigsen <jostein <at> secure.kjonigsen.net>,
 79944 <at> debbugs.gnu.org
Subject: Re: bug#79944: 30.2; bash-ts-mode fontification of command invocations
Date: Thu, 4 Dec 2025 22:23:49 -0800

> On Dec 4, 2025, at 7:43 PM, Robert Brown <robert.brown <at> gmail.com> wrote:
> 
> The patch looks good to me.  Thanks!
> 
> I somewhat agree with the philosophical digression.  Tree sitter fontification should be an extension of that provided by current language modes.  I'm interested in it because it's more accurate and more efficient.  I will configure tree sitter modes so that variable references, function calls, and pretty much all of the other new semantic distinctions are fontified using the default face.  My general guide is:  https://www.amazon.com/Human-Factors-Typography-Readable-Programs/dp/0201107457  The fontification provided by most IDEs these days ends up hurting readability.

Interesting book! I’m going to give it a read when I found the time. In general I agree, and the default tree-sitter fontification level doesn’t highlight every use of variables and functions: there won't be much left unfontified if it does.

Yuan

Message #25 received at 79944-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jostein Kjønigsen <jostein <at> secure.kjonigsen.net>
Cc: casouri <at> gmail.com, robert.brown <at> gmail.com, jostein <at> kjonigsen.net,
 79944-done <at> debbugs.gnu.org
Subject: Re: bug#79944: 30.2; bash-ts-mode fontification of command invocations
Date: Sat, 06 Dec 2025 14:35:53 +0200

> From: Jostein Kjønigsen <jostein <at> secure.kjonigsen.net>
> Date: Thu, 4 Dec 2025 08:51:20 +0100
> Cc: Robert Brown <robert.brown <at> gmail.com>,
>  Jostein Kjønigsen <jostein <at> kjonigsen.net>,
>  Yuan Fu <casouri <at> gmail.com>,
>  79944 <at> debbugs.gnu.org
> 
> I think instead changing it to font-lock-function-call-face would make it more consistent with the semantics of the other tree-sitter based major-modes we currently have in Emacs.
> 
> > 
> > Thanks.
> > 
> > Jostein and Yuan, WDYT?
> 
> If there's no big disagreements to the design, approach and philosophy outlined above, below is a patch which implements this change :) 

There was an agreement, so I've now installed the patch, and I'm
closing this bug.

Thanks.

Previous Next

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