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

[Gian Piero Carrubba]

* Please cc me as I'm not subscribed.

* [Sat, Mar 04, 2017 at 02:26:04PM -0500] Chet Ramey:
> 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).

I see. Frankly I think the wording is a bit convoluted and I would 
interpret it differently. More precisely, I would guess that the 
'preceding' in 'preceding word boundary' is in regard to 'the 
[character] preceding the cursor', so e.g. (upper means where the cursor 
is):

abc.def Ghi

the start is the character preceding the cursor (space), the stop is the 
word boundary *preceding the start* (f) and it would result in 
'abc.defGhi'. Similarly:

abc.defXghi -> abc.Xghi
abc.Def ghi -> abcDef ghi

and so on. I consider the 'closer to the cursor' reference as a way to 
differentiate between the multiple word boundary that could possibly 
exist *before the start* (f,d,c and a in the first example).

This means that, unless the cursor in on the first character of the 
line, using ^W would always delete at least a character. In other words, 
the interval of chars to be deleted is (stop,start].

Another thing that could be problematic, and for this I don't have an 
alternative interpretation, is the definition of a word boundary 
strictly as a character. Usually, boundaries are considered either as 
anchors that sit *between* characters or as one of the two contiguous 
characters, depending on the context. Defining the boundary only as a 
character is a bit misleading.

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

AFAICT, both vi (nvi) and ksh93 do not allow to edit previously entered 
lines using ^W (i.e.: in any of the examples, ksh93 does nothing 
wherever the cursor is located, and IMHO it's one of the most annoying 
behaviours for both ksh and vi).

They DO allow to delete characters with ^W as long as you don't enter 
command mode (Esc) after having typed them. So, for example, you can 
recall a previous line, insert new chars and delete them (and ONLY them) 
with ^W.

OTOH, both in vi (nvi) and ksh93:

'some word^W' -> 'some '
'some word ^W' -> 'some '

while in vi (nvi):
'some word.^W' -> 'some word'
'some word. ^W' -> 'some word'

and in ksh93:
'some word.^W' -> 'some '
'some word. ^W' -> 'some word'

I don't think to recall any program that is adopting the current 
behaviour of bash (but I may be wrong). Obviously this does not exclude 
the possibility that bash is right and other shells/editor are wrong.

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

As for my interpretation above, bash *have* to delete something but this 
is a case where not considering a boundary as an anchor is problematic.
IMHO, the correct behaviour should be:

'some w^W' -> 'some '

This is how vi (nvi), ksh93 and most other shells behave.

Anyway, given the description you posted, and wanting to strictly adhere 
to it, I guess bash should do:

'some w^W' -> 'some' (without the trailing space).

Thanks,
Gian Piero.

PS: All in all, anyway, I would ask to reformulate the POSIX description 
to be more descriptive and unambiguous.