Specifically, the 'e' and 'g_' commands seem inconsistent to me.
:help e says the cursor will be placed on the end of a word
(inclusive).
:help g_ says the cursor will be placed on the last nonblank character
in a line (also inclusive).
So, suppose I have a line with one word, like this:
anitdisestablishmentarianism
With 'selection' set to "inclusive", ^ve and ^vg_ do the same thing,
with a visual selection that looks like:
|anitdisestablishmentarianism|
With 'selection' set to "exclusive", ^ve gives:
|anitdisestablishmentarianism|
But ^vg_ gives:
|anitdisestablishmentarianis|m
This happens even with trailing whitespace on the line.
Why do two motions, both inclusive, that put the cursor in the same
place, create a different visual selection?
Not for me, 7.2.284, both give the same visual selection.
Regards, John
John Little cannot duplicate the behavior on 7.2.284, but I see it on
7.2.320 on Windows gvim launched with -N -u NONE.
If it isn't clear, I had to :set selection=exclusive to see the
puzzling behavior. I assume he did this.
Well, I thought I had. I checked my setting of the selection option,
and read it clearly as 'inclusive', which I decided is what you said.
However, now with selection=exclusive, I see what you report. With
^ve, the cursor is placed beyond the end of the word, even though
there's nothing there, and even with virtualedit blank. I see this
is according to the help for 'selection'.
It's like g_ is being treated as an exclusive motion when visual mode
is used.
Regards, John
> Forwarding to vim_dev from vim_use, seems to be a bug introduced since
> 7.2.284
>
> John Little cannot duplicate the behavior on 7.2.284, but I see it on
> 7.2.320 on Windows gvim launched with -N -u NONE.
>
> If it isn't clear, I had to :set selection=3Dexclusive to see the
> puzzling behavior. I assume he did this.
It's not clear to me what patch could have changed this. This change
will fix it for "g_". I wonder if there are other commands that have
the same problem.
*** ../vim-7.2.327/src/normal.c 2009-12-24 15:00:31.000000000 +0100
--- src/normal.c 2010-01-09 15:19:47.000000000 +0100
***************
*** 7873,7878 ****
--- 7873,7881 ----
&& vim_iswhite(ptr[curwin->w_cursor.col]))
--curwin->w_cursor.col;
curwin->w_set_curswant = TRUE;
+ #ifdef FEAT_VISUAL
+ adjust_for_sel(cap);
+ #endif
}
break;
--
From "know your smileys":
<>:-) Bishop
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
Same issue occurs with ge and gE .
I checked :helpg |inclusive
$, g$, g<End>, f{char}, t{char}, <C-End>, e, E, ge, gE
Another "issue": Given a line
abcd efgh
selection=exclusive, and Visual mode on:
Whether the cursor "|" is after the "c"
abc|d efgh
or after the "d"
abcd| efgh
in both cases, e moves the cursor to the end of "efgh".
When the cursor is after the "c", I expect it to move after the "d".
(gVim 7.2.218)
--
Andy
> Am 09.01.2010 15:48, schrieb Bram Moolenaar:
> > This change
> > will fix it for "g_". I wonder if there are other commands that have
> > the same problem.
>
> Same issue occurs with ge and gE .
These move backwards, thus the selection being exclusive doesn't matter.
Using "b" works similarly, the cursor position is not included, thus
using "b" right after "v" doesn't include the cursor position. Same for
"ge" and "gE".
> I checked :helpg |inclusive
> $, g$, g<End>, f{char}, t{char}, <C-End>, e, E, ge, gE
>
>
> Another "issue": Given a line
> abcd efgh
> selection=exclusive, and Visual mode on:
> Whether the cursor "|" is after the "c"
> abc|d efgh
> or after the "d"
> abcd| efgh
> in both cases, e moves the cursor to the end of "efgh".
> When the cursor is after the "c", I expect it to move after the "d".
>
> (gVim 7.2.218)
That's difficult to avoid, since the "e" works like "e" always works,
and then the selection is changed to include the cursor position.
Doing it otherwise could be considered wrong as well.
--
Why is it called "Windows"? "Gates" would be more appropriate...