bug-bash
[Top][All Lists]
Advanced

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

Re: bash 4.4 - (readline) regression in the behaviour of ^W in vi-mode


From: Chet Ramey
Subject: Re: bash 4.4 - (readline) regression in the behaviour of ^W in vi-mode
Date: Sat, 4 Mar 2017 14:26:04 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1

On 3/3/17 3:30 PM, Gian Piero Carrubba wrote:
> * Please cc me as I'm not subscribed.
> 
> * [Fri, Mar 03, 2017 at 09:38:04AM -0500] Chet Ramey:
>> On 3/3/17 5:47 AM, Gian Piero Carrubba wrote:
>>> Hello all,
>>>
>>> this is a copy of Debian bug 838437 [0]. I'm posting it here because I
>>> failed to find it mentioned in the ml archives. Please disregard if it's
>>> been already reported.

Debian bug reports only occasionally  make it to the mailing list.


> thank for your prompt response.
> It is related in the sense they both have been introduced by the same
> feature (I've got the workaround from there), but imho it should be treated
> differently (I actually consider the behaviour described in the other
> thread as correct). Following the examples provided in the previous mail,
> you can see that in some circumstances Ctrl-W does nothing or, maybe worse,
> it works the first time and not subsequent ones.

The Posix description of ^W in vi mode reads:

"Delete the characters from the one preceding the cursor to the preceding
word boundary. The word boundary in this case is the closer to the cursor
of either the beginning of the line or a character that is in neither the
blank nor punct character classification of the current locale."

So it specifies where you need to start (before the cursor), where to stop
(the preceding word boundary), and what the word boundaries are (something
that's not a blank or punctuation).  Unlike bash-4.3, punctuation
characters like `.' are not word boundaries.  I think that's how vi
behaves, but I'm not a vi user.

So if the cursor is at a space following a word, the "character preceding
the cursor" and "the preceding word boundary" are the same.  If the
cursor is on a `.' preceding a space, the space gets deleted before you
get to something that's a word boundary.  If you're on a `.' that
follows an `E', the character preceding the cursor and the preceding
word boundary are the same again.

For what it's worth, for each of the examples in your previous mail
message, ksh93 (ksh88 was used as the `reference implementation' for
Posix sh vi mode) does nothing.  Right now, you could make a case that
bash gets it wrong where it deletes something.  For example, if you're
on the `E' in `REMOVE', the character preceding the cursor and the
preceding word boundary are the same, so bash arguably shouldn't delete
anything.

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



reply via email to

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