bug-readline
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

readline-colored-completion-prefix in /etc/dircolors


From: Stefan Klinger
Subject: readline-colored-completion-prefix in /etc/dircolors
Date: Sun, 27 Aug 2023 14:17:54 +0200

Hello,

I'm reporting a bug (I think it is), and provide a trivial fix.  I'd
also like to contribute an improvement in the second half of this
mail.


The bug
=======

I'm using readline's `colored-completion-prefix`, and tried to set a
custom color for this.  This does not work, there seems to be an
incompatibility between `dircolors` (generating `$LS_COLORS`) and
readline's expectation of the “custom suffix”.

When I refer to changing `/etc/dircolors`, then this always implies
reloading, i.e., running

    # dircolors -b /etc/dircolors >| /etc/dircolors.bash

and starting a new `bash` which sources `/etc/dircolors.bash` from its
rc-file.

Note, that `dircolors` *requires* the file extension to be specified
with a leading dot:

    $ tail -1 dircolors_nodot
    readline-colored-completion-prefix 0;36

    $ dircolors $_
    dircolors: dircolors_nodot:63: unrecognized keyword 
readline-colored-completion-prefix

but

    $ tail -1 dircolors_withdot
    .readline-colored-completion-prefix 0;36

    $ dircolors $_
    
LS_COLORS='no=00:fi=00:bd=01;30:cd=01;30:di=1;34:do=40;33:ex=00;31:pi=40;33:ln=target:or=40;33;01:so=40;33:*.readline-colored-completion-prefix=0;36:';
    export LS_COLORS

Unfortunately, when specified with a dot, the setting does not have
the desired effect.  See reproduction below.


Version information
-------------------

Readline version 8.2.001-2 on Arch Linux:

    $ pacman -Q readline
    readline 8.2.001-2


Reproduction
------------

Reproduced with current master branch `7274faa`:

    $ git clean -xdf
    $ ./configure
    $ make

    $ grep colored-completion-prefix ~/.inputrc
    set colored-completion-prefix on
    $ echo "$LS_COLORS"
    
no=00:fi=00:bd=01;30:cd=01;30:di=1;34:do=40;33:ex=00;31:pi=40;33:ln=target:or=40;33;01:so=40;33:*.readline-colored-completion-prefix=0;36:

    $ cd examples/
    $ make
    $ ./rl
    readline$ rl→

In the last line, `→` inidcates hitting TAB.  Completions are listed
as expected, but the prefix is colored in the colors specified for
sockets, `so` in `$LS_COLORS`.

It works, however, if `LS_COLORS` is modified to contain the custom
suffix without a dot:

    $ 
LS_COLORS='no=00:fi=00:bd=01;30:cd=01;30:di=1;34:do=40;33:ex=00;31:pi=40;33:ln=target:or=40;33;01:so=40;33:*readline-colored-completion-prefix=0;36:'
 ./rl

This uses the desired color (cyan).  However, as described above,
`dircolors` refuses to set LS_COLORS accordingly.


A Fix
-----

Change the required suffix to `.readline-colored-completion-prefix`,
i.e., include the dot.

Obviously, I cannot push to git.savannah.gnu.org, so I ask you to pull
from my own clone:

    $ git remote add sk https://github.com/s5k6/readline
    $ git fetch sk
    $ git switch sk_fix_suffix


Suggested improvement
=====================

I've started working (see branch `sk_completion_prefix_color`) on the
following change:

Add a string-valued `completion-prefix-color`.  If unset, then the
matched prefix should not be colored.  Otherwise, its value should be
used as the color to hilight the matched prefix.

This would obsolete the boolean setting `colored-completion-prefix`,
and also the custom suffix in `$LS_COLORS`.

Reasons:

  * I find it awkward to set `LS_COLORS` to set readline's colors.
    Readline may be using the `ls` command's configuration for its own
    coloring needs, but `ls` should not be bothered with the way
    readline is configured.

  * It further pollutes the environment.  I do not see a reason to
    have this configuration (coloring of a metched prefix) placed in
    the environment, rather than in the anyway existing `inputrc`.

  * I find the concept of hijacking a “custom suffix” semantically
    wrong.  File suffixes (also: file types, like “socket”) are not
    involved when coloring the prefix.

I'm currently working on this, feedback is welcome.  A first approach
is in the branch `sk_completion_prefix_color`.  To use this, put

    set completion-prefix-color 32;3

in your inputrc file, which sould give green, oblique coloring of the
matched prefix.  The setting of `colored-completion-prefix`, and the
presence of the “custom suffix” in LS_COLORS are ignored, as I intend.

I'm a bit uneasy about a couple of things regarding the structure of
my code, though, and would have a couple of questions on my own.

Feedback is *very* welcome.  If this change has no chance of being
adopted, please stop me now =)

Kind regards
Stefan


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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]