Hi As stated here (https://lists.gnu.org/archive/html/bug-readline/2023-10/msg00025.html), the custom suffix in `$LS_COLORS` that is used for readline's "colored-completion-prefix" was "recently" changed to include a leading dot. A similar change was not made to the documentation of readline (and Bash), and this documentation still uses the original suffix without the leading dot. Although the documentation can simply be changed to use the new suffix, I argue that the correct fix would be to revert the suffix to its original value (without the leading dot).
>From here >(https://lists.gnu.org/archive/html/bug-readline/2023-08/msg00018.html), the original motivation for adding the leading dot seems to be that > `dircolors` *requires* the file extension to be specified with a leading dot >From what I could gather, dircolors has supported suffixes without leading dots for at least 20 years. The 2004 version of the `dir_colors(5)` man page from the first commit of the "man-pages" project shows the two ways in which to specify a suffix: > *extension color-sequence > Specifies the color used for any file that ends in extension. > > .extension color-sequence > Same as *.extension. Specifies the color used for any file that ends in > .extension. Note that the period is included in the extension, which > makes it impossible to specify an extension not starting with a period > .... > This form should be considered obsolete. This exact snippet also appears in the current version of the `dir_colors(5)` man page. The original suffix (without the dot) can be easily used with dircolors by simply using the non-obsolete syntax. Thus, the addition of the leading dot seems unnecessary, and it breaks all configurations that use the original suffix. (I could also just be unaware of a different version of dircolors that does not support this syntax.) If this is not sufficient to justify reverting the suffix to its original value, the documentation would need to be changed to use the new value. The documentation describes "readline-colored-completion-prefix" as a "suffix", which does not imply that a leading dot is required. For the sake of completeness: using the original suffix without the leading dot (as shown in the documentation) has no effect on the completion prefix in Bash version 5.2.32(1)-release on Void Linux. Related: Bug in readline when readline-colored-completion-prefix is set (https://lists.gnu.org/archive/html/bug-bash/2023-11/msg00147.html) Regards Daniël Gerbrand Haasbroek
