Re: bug: 'vi-fword' binding command does the same as 'vi-fWord'

[Chet Ramey]

On 1/1/20 2:48 PM, Andrey Butirsky wrote:
> On 01.01.2020 22:15, Chet Ramey wrote:
>> On 12/29/19 8:31 PM, Andrey Butirsky wrote:
>>> On 30.12.2019 04:26, Chet Ramey wrote:
>>>> That's the thing: it's not a bug. Function name matching is
>>>> case-insensitive, and always has been. This goes back as far as I can
>>>> easily
>>>> check right now, and even predates vi mode.
>>>>
>>> So how about my second suggestion then, to eliminate the confusion?
>>>
>>> Swap
>>> { "vi-bword", rl_vi_bword },
>>> to
>>> { "vi-bword", rl_vi_bWord },
>> A couple of things. One, that would be wrong, since you want "vi-bWord" to
>> map to `rl_vi_bWord' and "vi-bword" to map to `rl_vi_bword' for
>> consistency if nothing else. Two, how would that `eliminate the confusion'?
>> The result might be what you want, but it would change the behavior for
>> everyone who wants the historical behavior, breaking backwards
>> compatibility and introducing additional issues.
> 
> I'm not sure you understood me what the real problem is.

I get it. The matching is case-insensitive, rightly or wrongly. That's the
way it always has been. That behavior predates readline's vi mode.

You want "vi-bword" to map to rl_vi_bword, but the mapping is currently to
rl_vi_bWord, because "vi-bWord"/rl_vi_bWord appears first in the function
name list and the name matching is not case sensitive. What's worse, that
means you can map "vi-bword" and "vi-bWord" to different key sequences and
get inconsistent results.

This is only a problem for the lowercase versions of these functions.
Consider the person who is trying to map to the function corresponding to
"vi-bWord". Right now, it works, mapping to rl_vi_bWord, even if the name
matching is case-insensitive, due to the ordering.

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

There's no sense in flipping the problem just so you can get the result you
want while someone else is newly inconvenienced.

That's why I suggest using the unambiguous command names.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    address@hidden    http://tiswww.cwru.edu/~chet/