On 1/1/20 2:48 PM, Andrey Butirsky wrote:
Of course I want "vi-bWord" to map to `rl_vi_bWord' and "vi-bword" to map
to `rl_vi_bword', but the problem is bash just doesn't work that way -
instead, it really maps "vi-bword" to `rl_vi_bWord', but this behavior is
hidden and not obvious from the code (I was caught to it by myself twice,
and both times it was a pain to dig it out). So if the mapping would
correspond to its real behavior, it would eliminate the confusion, just it.
If I were to make a change along the lines you suggest, removing the
mapping to rl_vi_bword and having both "vi-bword" and "vi-bWord" map to
rl_vi_bWord, nothing would change. The behavior would still be the same.
The mapping would still be `wrong', and the list would be just as
misleading ("why have two names differing in case for the same function,
when there are two functions available?"), though in a different way.
If I were to make a change that swapped the order of the two name-binding
pairs in the list, you would get the behavior you want: "vi-bword" would
map to rl_vi_bword. However, so would "vi-bWord". You've changed the
problem, but it's ok because you've changed it to the result you want.
Someone who expects the historical behavior, which I admit is due to the
ordering in the list, would now get different results. So that's not really
a solution.
Considering the historical behavior, you said it always been
case-insensitive, so I suppose it just wouldn't change.
The historical name matching behavior is case-insensitive. The results are
inherently ambiguous in this case due to poor bindable command name choices
nearly thirty years ago.
It's `correct' to have "vi-bWord"/rl_vi_bWord and "vi-bword"/rl_vi_bword
mappings even if the name matching isn't right due to case insensitivity.
It's never going to be correct all the time, but I'd prefer to leave them
alone for backwards compatibility and say they're deprecated.