Bug: Ex command after "motion force" cannot be aborted properly

[glts]

In Operator-pending mode it is possible to use Ex commands to move the
cursor. When editing the command-line in this situation, <Esc> normally
aborts the whole operation. For example, in normal mode:

d:call<Esc>

This command has no effect.

But when a "motion force" has been given before entering the
command-line, the command cannot be aborted. To reproduce, again in
normal mode:

dv:call<Esc>
dV:call<Esc>

These commands delete one character and one line respectively.

David Bürgin

[Christian Brabandt]

Hi glts!

On Mi, 27 M�r 2013, glts wrote:

> In Operator-pending mode it is possible to use Ex commands to move the
> cursor. When editing the command-line in this situation, <Esc> normally
> aborts the whole operation. For example, in normal mode:
>
> d:call<Esc>
>
> This command has no effect.

But it doesn't really abort.

>
> But when a "motion force" has been given before entering the
> command-line, the command cannot be aborted. To reproduce, again in
> normal mode:
>
> dv:call<Esc>
> dV:call<Esc>
>
> These commands delete one character and one line respectively.

Here is a patch, that checks, whether the ex command could be executed
and also whether the command possibly generated an error.

regards,
Christian
--

[glts]

Christian, thanks for looking into this.

On Wed, Mar 27, 2013 at 4:01 PM, Christian Brabandt <cbl...@256bit.org> wrote:

> On Mi, 27 Mär 2013, glts wrote:
>> d:call<Esc>
>>
>> This command has no effect.
>
> But it doesn't really abort.

I don't understand. The command is cancelled silently, just as it is
when you cancel other Operator-pending commands, e.g. "d3<Esc>". This is
what I would expect.

> Here is a patch, that checks, whether the ex command could be executed
> and also whether the command possibly generated an error.

I don't think this is the right solution. The behaviour should be the
same as for other Operator-pending commands: "d<Esc>", "dv<Esc>",
"d:<Esc>". This isn't erroneous input and we don't want Vim to beep.

David

[Christian Brabandt]

On Wed, March 27, 2013 17:18, glts wrote:
> Christian, thanks for looking into this.
>
> On Wed, Mar 27, 2013 at 4:01 PM, Christian Brabandt <cbl...@256bit.org>
> wrote:

>> On Mi, 27 M�r 2013, glts wrote:
>>> d:call<Esc>
>>>
>>> This command has no effect.
>>
>> But it doesn't really abort.
>
> I don't understand. The command is cancelled silently, just as it is
> when you cancel other Operator-pending commands, e.g. "d3<Esc>". This is
> what I would expect.

Not it isn't. Simple case:
:h
d:call<esc>

(Note the error message).

regards,
Christian

[glts]

I still don't think it should be an error. Sometimes when you start
typing "d3..." you realize you wanted "change" instead of "delete", so
you press <Esc> and start again.

For me, "d:call <Esc>" is the same thing. Perhaps you want to use a
custom function but you forgot to source the relevant file, so you
cancel and start again. I don't feel this is an error. What do you
think?

On Wed, Mar 27, 2013 at 5:35 PM, Christian Brabandt <cbl...@256bit.org> wrote:
> On Wed, March 27, 2013 17:18, glts wrote:
>> On Wed, Mar 27, 2013 at 4:01 PM, Christian Brabandt <cbl...@256bit.org>
>> wrote:

>>> On Mi, 27 Mär 2013, glts wrote:
>>>> d:call<Esc>
>>>>
>>>> This command has no effect.
>>>
>>> But it doesn't really abort.
>>
>> I don't understand. The command is cancelled silently, just as it is
>> when you cancel other Operator-pending commands, e.g. "d3<Esc>". This is
>> what I would expect.
>
> Not it isn't. Simple case:
> :h
> d:call<esc>
>
> (Note the error message).

Oh right, I didn't catch that. All the more reason to sort out the root
cause.

[Christian Brabandt]

Hi glts!

On Mi, 27 M�r 2013, glts wrote:

> I still don't think it should be an error. Sometimes when you start
> typing "d3..." you realize you wanted "change" instead of "delete", so
> you press <Esc> and start again.
>
> For me, "d:call <Esc>" is the same thing. Perhaps you want to use a
> custom function but you forgot to source the relevant file, so you
> cancel and start again. I don't feel this is an error. What do you
> think?

Ok, what do you think of this updated patch?

regards,
Christian
--
"Verstehen sie etwas vom Theater?"
"Ja, wenn laut genug gesprochen wird."

[glts]

Christian,

On Wed, Mar 27, 2013 at 11:01 PM, Christian Brabandt <cbl...@256bit.org> wrote:
> Ok, what do you think of this updated patch?

Won't there be a redundant call to clearop() now when cancelling
ordinary Ex commands? I suppose it should work though. Thanks.

Personally, I'd rather not patch up bugs where the root cause is
unknown. In this case, the fact remains that "dv:<Esc>" deleted one
character and "dV:<Esc>" deleted one line, and "d:<Esc>" didn't. So I
would prefer to find out how this was possible -- maybe there's more.

[glts]

Christian,

On Wed, Mar 27, 2013 at 11:01 PM, Christian Brabandt <cbl...@256bit.org> wrote:
> Ok, what do you think of this updated patch?

You are of course correct.

I now see that a motion given with an Ex command is exclusive by
default, and "v" and "V" toggle inclusive/exclusive, and that is why
eventually the character or the line under the cursor are deleted.

I think your solution is fine, thanks a lot. I have attached a patch
that avoids calling clearop() when it isn't necessary and avoids calling
both clearop() and clearopbeep(), it's just a little bit more verbose.

[glts]

Sorry for being spammy:

On Thu, Mar 28, 2013 at 1:16 PM, glts <676c...@gmail.com> wrote:
> On Wed, Mar 27, 2013 at 11:01 PM, Christian Brabandt <cbl...@256bit.org> wrote:
>> Ok, what do you think of this updated patch?
>

> I think your solution is fine, thanks a lot. I have attached a patch
> that avoids calling clearop() when it isn't necessary and avoids calling
> both clearop() and clearopbeep(), it's just a little bit more verbose.

Nonsense. The patch avoids
a) calling clearop() when it isn't necessary and
b) *not beeping* when did_emsg == TRUE and cmd_result == FAIL