[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Unnecessary change to readline-colored-completion-prefix
From: |
Daniël Gerbrand Haasbroek |
Subject: |
Re: Unnecessary change to readline-colored-completion-prefix |
Date: |
Sat, 19 Oct 2024 23:20:56 +0200 |
>> 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).
>
> As the original bug report observed, this does not work with at least
> some versions of dircolors, so you couldn't specify a value for LS_COLORS
> without the dot. That was the entire point of the bug report.
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.
Additionally, the bug seems to have been encountered on Arch Linux,
whose `dircolors` version definitely supports the "*extension" syntax.
Essentially, I'm just worried that this breaking change is based on a
simple misunderstanding about the suffixes supported by `dircolors`.
>> 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
>
> The existing code, whatever version it was, certainly did. `dircolors'
> rejected the suffix without the leading dot.
> It appears that there were versions of dircolors out there that didn't
> accept the suffix without a dot.
If you are certain that there are versions of `dircolors` that do not
accept the suffix without a dot, then my argument is unfounded. I
just couldn't find any evidence of such a version, and there didn't
seem to be enough justification for a breaking change (to me, at
least). On the other hand, I'm not very familiar with the maintenance
of GNU software (or free software in general), and I don't really know
how much justification is required for such a change.