On 4/14/18 9:29 PM, Nuzhna Pomoshch wrote:
>> On Mon, 5/29/17, Chet Ramey <chet.ra...@case.edu> wrote:
>
>>> On 5/28/17 3:29 PM, Nuzhna Pomoshch wrote:
>
>>> $ bind -m vi-command -p | grep delete-char
>>> # backward-delete-char (not bound)
>>> "\e[3~": delete-char
>>> # delete-char-or-list (not bound)
>>> # forward-backward-delete-char (not bound)
>>>
>>> You will note that those are identical, yet (still) hitting the delete key
>>> (at the end of the line) pops up (arg: 3) on the readline 6.3 machine.
>>>
>>> Any other ideas as to what could be causing this?
>
>> OK, I think I got it. I was able to reproduce it with this additional
>> detail. The issue is a failing readline command (delete-char with no chars
>> to delete, in this case) at the end of a multi-key sequences. The problem
>> is that readline wrongly chooses to back up the key sequence because the
>> command doesn't return 0. Readline needs to better validate the return code
>> before backtracking. This will be fixed in the next bash and readline devel
>> branch pushes.
>
> Can you tell me what versions this will be fixed in?
It's been fixed in the bash and readline devel branches since this message.
The fix will appear in the next bash and readline releases. I may release
a patch, but I'm still trying to get bash-5.0-alpha out the door.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
_______________________________________________
Bug-readline mailing list
Bug-readline@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-readline
