Inconsistent overkill behavior on various motions

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Inconsistent overkill behavior on various motions

Brennan Vincent
I am investigating the behavior of various motions when [count] exceeds
the actual number of objects.

Given buffer "abc abc":

"2$" (with cursor on first column) does nothing (presumably an error).
"2^" (cursor on last column) has the same behavior as "^".
"2w" (cursor on first column) jumps to the last character on the line
(same behavior as "2e").

Comparison with the other vi implementations I have available:

Neovim matches the behavior of Vim.

Nvi errors on "2^"; otherwise the behavior is the same as Vim.

Zsh with `bindkey -v` matches Vim.

Readline apps in vi mode (e.g., bash with `set -o vi`) go as far as
possible in all three cases (i.e., they match Vim, except that on "2$"
they jump to the end of the line).


--
--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/5ac35684-8597-b9bd-a744-fb4f933d9b90%40umanwizard.com.
Reply | Threaded
Open this post in threaded view
|

Re: Inconsistent overkill behavior on various motions

Brennan Vincent
On 10/18/20 1:12 AM, Brennan Vincent wrote:

> I am investigating the behavior of various motions when [count] exceeds
> the actual number of objects.
>
> Given buffer "abc abc":
>
> "2$" (with cursor on first column) does nothing (presumably an error).
> "2^" (cursor on last column) has the same behavior as "^".
> "2w" (cursor on first column) jumps to the last character on the line
> (same behavior as "2e").
>
> Comparison with the other vi implementations I have available:
>
> Neovim matches the behavior of Vim.
>
> Nvi errors on "2^"; otherwise the behavior is the same as Vim.
>
> Zsh with `bindkey -v` matches Vim.
>
> Readline apps in vi mode (e.g., bash with `set -o vi`) go as far as
> possible in all three cases (i.e., they match Vim, except that on "2$"
> they jump to the end of the line).
>
>

Actually it seems nvi matches vim in all cases. So bash/readline is the
only outlier.

--
--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/05399976-c96e-a769-ae9e-bd2867808749%40umanwizard.com.
Reply | Threaded
Open this post in threaded view
|

Re: Inconsistent overkill behavior on various motions

Tim Chase
In reply to this post by Brennan Vincent
On 2020-10-18 01:12, Brennan Vincent wrote:
> "2$" (with cursor on first column) does nothing (presumably an
> error).

For the record, "$" does take a count, going to the end of the line
count-1 lines down.  With only the single line, there's no count+1
line to go to, so both (n)vi and vim rightfully errors at you.

  :help $

With more than one line you can observe the expected behavior.  I'd
use "$" with a count more often if it did "count" lines rather than
"count-1" lines, because "count-1" requires doing the math in my
head.  Just a little friction.

> "2^" (cursor on last column) has the same behavior as "^".
> Nvi errors on "2^"; otherwise the behavior is the same as Vim.

"^" doesn't take a count, so both (n)vi (at least here on FreeBSD &
OpenBSD) and vim ignore attempts to provide a count.  I could see it
going either way here -- either erroring or just ignoring it.

> "2w" (cursor on first column) jumps to the last character on the
> line (same behavior as "2e").

There are some small "e" implementation differences between vi and
vim as detailed in `:help WORD` (right above `:help object-motions`)
but I don't think you're hitting this known case.  I was surprised to
see that this nuance you encountered wasn't documented (as best I can
tell).

-tim






--
--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20201018074222.36581e4f%40bigbox.attlocal.net.
Reply | Threaded
Open this post in threaded view
|

Re: Inconsistent overkill behavior on various motions

Brennan Vincent
On 10/18/20 8:42 AM, Tim Chase wrote:
> For the record, "$" does take a count, going to the end of the line
> count-1 lines down.  With only the single line, there's no count+1
> line to go to, so both (n)vi and vim rightfully errors at you.

I get it. My point was that this logic applies for some motions, but not
others. In particular `w`, `j` and many others will go as far as they
can, not error if the count is too high.

--
--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/674914b4-636f-da89-14c0-fcd70c4f4d6a%40umanwizard.com.