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