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