[Top][All Lists]

[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: Gian Piero Carrubba
Subject: Re: bash 4.4 - (readline) regression in the behaviour of ^W in vi-mode
Date: Sun, 5 Mar 2017 18:37:23 +0100
User-agent: NeoMutt/20170113 (1.7.2)

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

Gian Piero.

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

reply via email to

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