tl;dr: I suggest a nicer approach to configure the common completion
prefix, preliminary implementation is here [3].
Hello,
in 2023, I had little success in changing the colouring used by
readline for the common completion prefix. Back then, I attributed [1]
this to a presumed (incorrectly) incompatibility between `dircolors`
and readline's expectation of the “custom suffix” it finds in
`$LS_COLORS`.
In 2024, Daniël raised concerns that the "fix" was an unnecessary,
breaking change, and correctly analysed [2] the situation:
> My concern is that the author of the original bug report might simply
> have been unaware of the `dircolors` configuration syntax that allows
> for suffixes without leading dots. This concern is based on the fact
> that the original bug report never mentions the "*extension" syntax;
> the bug is purely based on the obsolete ".extension" syntax.
You nailed it. =(
Okay, I've messed this up. My sincere apologies!
At that point, I was not subscribed to the list anymore (I'm afraid, I
have to be economical with the amount of lists I follow), otherwise I
would have written this earlier.
Because, aside from a lack of understanding of the `dircolors` syntax,
my original post [1] also contained a second approach that I would
like to raise again:
To me, it feels wrong to have the colouring of the completion prefix
defined in `$LS_COLORS`. The prefix colouring is not used by `ls` (we
all hope `ls` never finds it), the completion prefix is not a file
extension or file type by any stretch of imagination, it should have
nothing to do with `dircolors`, and IMHO it should not be in the
environment.
Also, there are currently two places that control completion prefix
colouring, the boolean variable `colored-completion-prefix` in
`~/.inputrc`, plus the entry in `$LS_COLORS`.
I was suggesting to combine this into a single, string-valued variable
in `~/.inputrc`, which contains the colour code if colouring is
desired, and is unset otherwise:
The single line
set completion-prefix-color 32;4
in `inputrc` would replace the two lines
set colored-completion-prefix on
*readline-colored-completion-prefix 32;4
currently spread out to `inputrc` and `dircolors`.
The new approach would not involve `$LS_COLORS` when colouring the
common prefix, which also makes changing this value much easier (no
chin-ups required to get this into the environment of every process).
I do maintain that this is a much nicer approach.
I have a preliminary implementation [3] for you to review. Consider
this a draft, I think I have not fully understood the interaction
between `completion-prefix-display-length` and
`colored-completion-prefix` hinted at in file `CHANGES` line 109!
The branch `sk_completion_prefix_color` is based on the current
`master` (15970c4) of readline.
$ git remote add s5k6 'g...@github.com:s5k6/readline.git'
$ git fetch s5k6 sk_completion_prefix_color
$ git sw sk_completion_prefix_color
$ ./configure && make && make -C examples
Prepare a modified `inputrc` file, the following copies your
`/etc/inputrc`:
$ sed '/colored-completion-prefix/d' /etc/inputrc > inputrc_mod
$ echo 'set completion-prefix-color 46;30' >> inputrc_mod
$ LS_COLORS= INPUTRC=inputrc_mod examples/rl <<< $'pa\t'
This should list the files in the current directory starting with
`pa`, and this very prefix should be highlighted.
According to feedback, I'm willing to put a more effort into this,
e.g., fixing coding style or updating documentation.
Cheers
Stefan
[1]: https://lists.gnu.org/archive/html/bug-readline/2023-08/msg00018.html
[2]: https://lists.gnu.org/archive/html/bug-readline/2024-10/msg00004.html
[3]: https://github.com/s5k6/readline/tree/sk_completion_prefix_color
--
Stefan Klinger, Ph.D. -- computer scientist o/X
http://stefan-klinger.de /\/
https://github.com/s5k6 \
I prefer receiving plain text messages, not exceeding 32kB.
