{count}v command

[Marcin Szamotulski]

Dear Vim Dev,

I recently found that v with count remembers the previous visual area.
I found that it is not always true, which seems strange to me (is this
a feature or a bug?). For example if I do "v{motion}y", then "1v", as
should, selects the same are in the current position. But if I do
"v{motion}<esc>" or "v{motion}<c-c>" then "1v" doesn't remember the
last visual area but the previous one. With <esc>/<c-c> I thing it
would be nice if <esc> could remember the last area and <c-c> don't
(this already happens with some features: for example <c-c> doesn't
trigger InsertLeave autocommands when leaving the insert mode.)

Best regards,
Marcin Szamotulski

[Ingo Karkat]

This has been discussed before:

https://groups.google.com/d/topic/vim_dev/381bdn3wuuM/discussion

From Bram:
> > The idea of "1v" is that a Visual operation can be repeated at another
> > location. Thus the area is only stored when performing an operation.

Like you, some found this behavior unexpected, but we couldn't convince Bram to
change this (mostly to avoid breaking stuff that potentially relies on this
behavior), and no patches were put forward.

-- regards, ingo

[Marcin Szamotulski]

> --
> You received this message from the "vim_dev" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php

Good to know.

Is there a VimL workaround, or a plugin for this?

Best,
Marcin

[Ingo Karkat]

You'd have to determine the dimensions from the '< and '> marks, and create a
new visual selection with the same dimensions.

Or (simpler, but more hackish) just make a no-op modification to the selection,
e.g. with gu followed by :undo, or maybe g?gvg?.

-- regards, ingo

[Marcin Szamotulski]

g?gvg? is really nice, I'll give it a try. I tested it over digraphs,
and it works.

Thanks,
Marcin

[ZyX]

> g?gvg? is really nice, I'll give it a try. I tested it over digraphs,
> and it works.

You can also use

:<C-u><Esc>
. Unlike g? workaround it alters neither undo nor command history.

[Ingo Karkat]

Great input, ZyX! For me, it even works without the <C-u>, just :<Esc>. Though
this looks like a bug to me: I would understand that a no-op command like
:<C-u>echo<CR> would be treated as a modification, but an aborted command
definitely does not count as a modification; it also isn't added to the history.
I guess this special behavior is just a side effect of a simple implementation
that doesn't take command aborts into account.

The more I learn about it, the more I would prefer that {count}v _always_ uses
the previous selection (as proposed here again), modification yes or no. But I
guess we would need more vocal support to sway Bram, so please speak up! (Or
voice your concerns if you happen to know someone/thing that relies on the
current behavior.)

-- regards, ingo

[ZyX]

> Great input, ZyX! For me, it even works without the <C-u>, just :<Esc>. Though
> this looks like a bug to me: I would understand that a no-op command like
> :<C-u>echo<CR> would be treated as a modification, but an aborted command
> definitely does not count as a modification; it also isn't added to the history.

If it is typed (and that is how I tested it) then it adds to the history.
Even if it is not typed then it may move the cursor (see :h cpo-x). You need to use `<C-c>` to abort in `:<Esc>`, but it works for mappings only (I mean, not altering history in this case: typed `<C-c>` adds «'<,'>» to history as well).

> I guess this special behavior is just a side effect of a simple implementation
> that doesn't take command aborts into account.
>
> The more I learn about it, the more I would prefer that {count}v _always_ uses
> the previous selection (as proposed here again), modification yes or no. But I
> guess we would need more vocal support to sway Bram, so please speak up! (Or
> voice your concerns if you happen to know someone/thing that relies on the
> current behavior.)

I did not knew about {count}v until that thread you mentioned earlier. Neither I know about anything that relies on {count}v, including {count}v behavior currently being discussed.

It seems more consistent to me if gv and {count}v remembered the same selection though. But I have no voice here: no matter which behavior {count}v will show I am much unlikely to use it: to repeat selection operation it is *me* who must remember the last visual selection area or I am ending up with {count}v selecting random amount of characters (from my point of view, not from computer). I never remember it, only what *semantic elements* I selected, not what *amount of characters*. And my style of writing plugins dictates me to avoid altering vim state as much as possible, including altering current vim selection.

Hence the conclusion: {count}v using aborted selection seems better then {count}v using only selection that was operated upon, but I will use neither.