[Top][All Lists]

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

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

From: Andrey Butirsky
Subject: Re: bug: 'vi-fword' binding command does the same as 'vi-fWord'
Date: Thu, 2 Jan 2020 00:40:50 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:72.0) Gecko/20100101 Thunderbird/72.0

On 01.01.2020 23:59, Chet Ramey wrote:
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.

I'm for this "solution". It would change that what you see in the code is what you get from the actual program behavior.
IMO it's far more important than that misleading you provided.
If you are disagree with me, can we at least have comments at the ambiguous maps?

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.

I think then we should update documentation on this, it's really makes problems as it is right now.

reply via email to

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