GNU bug report logs - #77746
[PATCH] sh-mode: Fix incorrect word syntax for punctuation in sh-mode

Previous Next

Full log

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

From: James Cherti <contact <at> jamescherti.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77746 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, juri <at> linkov.net
Subject: Re: bug#77746: [PATCH] sh-mode: Fix incorrect word syntax for
 punctuation in sh-mode
Date: Tue, 15 Apr 2025 07:21:08 -0400

Hello Eli,

The issue occurs in both sh-mode and bash-ts-mode.

This patch resolves it for me in both modes.

(I am using the first patch that marks !%^~:., as
punctuation. It includes '.'. In my workflow, I find little
value in completing commands within Bash scripts. I
prioritize completing variables and functions, as they are
more relevant to the script’s logic and structure.)

--
James Cherti
GitHub: https://github.com/jamescherti
Website: https://www.jamescherti.com/

On 2025-04-15 02:15, Eli Zaretskii wrote:
>> Date: Mon, 14 Apr 2025 15:29:44 -0400
>> Cc: eliz <at> gnu.org, 77746 <at> debbugs.gnu.org, juri <at> linkov.net
>> From: James Cherti <contact <at> jamescherti.com>
>>
>>
>> On 2025-04-14 13:23, Stefan Monnier via Bug reports for GNU Emacs, the
>> Swiss army knife of text editors wrote:
>>>> 1. Completion
>>>> --------------
>>>> Given the variable name `varname` in a comment,
>>>> followed by ".":
>>>>     #!/usr/bin/env bash
>>>>     # The name of this variable is varname. Code:
>>>>     var
>>>>
>>>> Completing "var" includes "varname." in the list of
>>>> completions.
>>>
>>> `varname.` is a valid command name and at the spot where you have `var`
>>> above, you could very well be completing a command rather than a variable.
>>>
>>>> (e.g. dabbrev completion. I am using Corfu/Cape,
>>>> which displays all suggestions)
>>>
>>> dabbrev doesn't even try to distinguish whether you're completing a var
>>> or a command or a type or anything else for that matter, so it's mostly
>>> unavoidable that it includes "useless" candidates (and that it misses
>>> valid candidates, as well).  IOW you can't argue that it's correct or
>>> not: you need to argue whether something will be usually useless or not.
>>>
>>>> 2. Highlight symbol at point
>>>> ----------------------------
>>>> When the cursor is on the comment `varname.`,
>>>> Emacs highlights `varname.` instead of `varname` when
>>>> using `(hi-lock-face-symbol-at-point)`:
>>>>     #!/usr/bin/env bash
>>>>     # The name of this variable is varname. Code:
>>>>     var
>>>
>>> Same here.  `varname.` is a valid command name so it can make perfect
>>> sense to highlight it.  Admittedly, I'd never seen a command with a `.`
>>> at the end, but removing `.` from the symbol constituents would rule out
>>> not just `varname.` but also all commands with a `.` in the middle of
>>> their names:
>>>
>>>       % ls /usr/bin/??*.* | wc
>>>           180     180    4274
>>>       %
>> Yes, commands like mkfs.ext4 contain '.' and are valid.
>> However, while :,!%^~ are valid characters for commands,
>> it's rare to see them used in command names. For instance, I
>> have no commands on my system that contain :,!%^~ despite
>> having 3,843 files in /usr/bin/.
>>
>> Perhaps this patch could be adjusted by removing '.' (given
>> its common use in command names), and keeping :,!%^~
>> as punctuation for variable names.
>>
>> (Removing '.' would not only cover the majority of
>> command/function names but also prevent using `!%^~:,` as
>> symbol constituents, resulting in more accurate variable
>> symbols.)
> 
> Did you try the tree-sitter based bash-ts-mode?  If you did, does it
> solve this problem better than sh-mode?
> 
> 
> 

Previous Next

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