Fwd: Strange motions.

[Nikolay Pavlov]

---------- Forwarded message ----------
From: "Paul Isambert" <zappat...@free.fr>
Date: Jul 14, 2013 2:12 PM
Subject: Strange motions.
To: "vim_use" <vim...@googlegroups.com>
Cc:

Hello all,

Working on Leonardo’s question regarding “dd”, I stumbled on the
following: “g$” seems to be sometimes inclusive, sometimes exclusive,
in ways that elude me. I might be misunderstanding something, but if I
don’t it looks like a bug to me.

Suppose you have the following two lines:

    abc
    def

You’re on “a” and type “dg$”; characters up to (and including) “c” are
deleted. On the other hand, if you type “d2g$”, then deletion goes to
“e”, leaving “f”. If you add “v” in both cases (“dvg$” and “dv2g$”)
then the pattern is reversed: in the first case “c” is not deleted, in
the second case “f” is deleted. So the first motion is inclusive by
default, and the second is exclusive; “v” reverses that (as it is
meant to do).

Second oddity: if instead of deleting you’re moving in virtual mode,
then the motion is always inclusive: “vg$” includes “c”, “v2g$”
includes “f”.

Third oddity: suppose you have one long, wrapped line instead of two
(the tilde is supposed to indicate wrapping):

    abc
    ~ def

Again, you’re on “a”. Deletion works as in the previous case: “c” is
included, “f” is not. But now visual mode excludes the last character:
“vg$” selects “ab”, not “abc”; “v2g$” excludes “f” unless it is the
last character of the (real) line, so in this case it would be
included, but not in the following:

    abc
    ~ def
    ~ ghi

I’ve never really been comfortable with in-/exclusiveness of motion,
but here it definitely doesn’t make any sense to me.

And now a second, unrelated question, since I’m at it: “Xdd”, where
“X” is a count, doesn’t do anything if you’re on the last line and X is
larger than 1; in other words, Vim doesn’t delete as many lines as
possible; instead, it deletes nothing. Now if you’re not on the last
line, Vim does delete as many lines as possible, even if X is larger
than the number of remaining lines; e.g. “5dd” deletes 2 lines when
you’re on the last but one line. Is there any rationale for this
difference in behavior?

Best,
Paul

--
--
You received this message from the "vim_use" 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

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Bram Moolenaar]

I suspect the behavior of g$ has not been defined very well.

With a count it uses the same function as "gj", which resets the
"inclusive" flag. That looks wrong, I'll make a patch for that.

Not so sure about the Visual mode commands. The 'selection' option also
matters and makes this more complex.

> And now a second, unrelated question, since I’m at it: “Xdd”, where
> “X” is a count, doesn’t do anything if you’re on the last line and X is
> larger than 1; in other words, Vim doesn’t delete as many lines as
> possible; instead, it deletes nothing. Now if you’re not on the last
> line, Vim does delete as many lines as possible, even if X is larger
> than the number of remaining lines; e.g. “5dd” deletes 2 lines when
> you’re on the last but one line. Is there any rationale for this
> difference in behavior?

This is intentionally implemented this way in cursor_down().
It doesn't say so, but it is most likely to be Vi compatible.

--
BLACK KNIGHT: None shall pass.
ARTHUR: I have no quarrel with you, brave Sir knight, but I must cross
this bridge.
BLACK KNIGHT: Then you shall die.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///