[vim/vim] getcurpos()[4] {curswant} returns 2147483647 after $ motion (#4464)

[mg979]

Describe the bug
getcurpos()[4] (curswant) returns 2147483647 after $ motion

To Reproduce
Detailed steps to reproduce the behavior:

1. Run vim --clean (or gvim --clean, etc.)
2. Edit any file
3. Type

:au CursorMoved * echo getcurpos()[4]

then motion $ on a line with text.

4. Describe the error
   getcurpos()[4] returns 2147483647, and that is shown in the command line.
   This means curswant is actually set to that value, and pressing j or k after that still shows that value.
   It doesn't happen if the motion is done when already at last character in the line.

Expected behavior
a value == virtcol("$") I guess?

Environment (please complete the following information):

• Vim version [e.g. 8.1.1408] (bug is present also in vim 8.0)
• OS: debian stretch
• Terminal: xfce4-terminal

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub

[Christian Brabandt]

That is the expected value for "move the cursor to the end of the line regardless how long the line is". Not a bug

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

---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/vim/vim/issues/4464%40github.com.
For more options, visit https://groups.google.com/d/optout.

[mg979]

Closed #4464.

[Gianmaria Bajo]

Il giorno sabato 1 giugno 2019 09:07:56 UTC+2, Christian Brabandt ha scritto:
> That is the expected value for "move the cursor to the end of the line regardless how long the line is". Not a bug

Thanks, I see now. I'll close the issue then.

[lacygoill]

I understand that there is a technical reason behind this value:

That's intentional. Vim defines a MAXCOL value which is used to
indicate the cursor is at the end of the line without specifically
requiring knowing the line length ahead of time. This allows the
behavior to stay the same even if the line length changes. Some of its
uses are purely internal, but it does have external visibility in the
case of commands like getpos().

Source: https://groups.google.com/g/vim_dev/c/oCUQzO3y8XE/m/opuczWwCtCsJ

But I still think that it looks unexpected for a plugin author. I wonder whether it would make sense to at least change the output of getpos():

vim9script
setline(1, 'some text')
exe "norm! V\e"
echom getpos("'>")

[0, 1, 2147483647, 0]

Otherwise, we have to fix it like this:

vim9script
setline(1, 'some text')
exe "norm! V\e"
var pos: list<number> = getpos("'>")
pos[2] = col([pos[1], '$'])
echom pos

[0, 1, 10, 0]

As an example, this is what the vim-exchange plugin has to do here.

If it can't be changed because it would break the compatibility with existing legacy Vim scripts, maybe we could limit this change to Vim9 scripts?

—
You are receiving this because you are subscribed to this thread.

Reply to this email directly, view it on GitHub, or unsubscribe.

[mg979]

I think it's working as intended, the problem is maybe that the behaviour is undocumented.

—
You are receiving this because you are subscribed to this thread.

Reply to this email directly, view it on GitHub, or unsubscribe.

[lacygoill]

Interestingly enough, getpos() is affected but not getcharpos():

vim9script
setline(1, 'some text')
exe "norm! V\e"
echom getpos("'>")

[0, 1, 2147483647, 0]

vim9script
setline(1, 'some text')
exe "norm! V\e"

echom getcharpos("'>")

[0, 1, 9, 0]

Which seems inconsistent.

—
You are receiving this because you are subscribed to this thread.

Reply to this email directly, view it on GitHub, or unsubscribe.

[Yegappan Lakshmanan]

Hi,

On Fri, Mar 5, 2021 at 4:55 AM lacygoill <vim-dev...@256bit.org> wrote:

I understand that there is a technical reason behind this value:

That's intentional. Vim defines a MAXCOL value which is used to
indicate the cursor is at the end of the line without specifically
requiring knowing the line length ahead of time. This allows the
behavior to stay the same even if the line length changes. Some of its
uses are purely internal, but it does have external visibility in the
case of commands like getpos().

Source: https://groups.google.com/g/vim_dev/c/oCUQzO3y8XE/m/opuczWwCtCsJ

But I still think that it looks unexpected for a plugin author. I wonder whether it would make sense to at least change the output of getpos():

If a plugin uses getcurpos() to save the current cursor position and then restores

the cursor position using setpos(), then changing the return value of

getcurpos() will break functionality.

Consider the following text in a buffer:

-------------------

123

123456

-------------------

If you position the cursor on '3' in the first line by using '$' then press j, then the

cursor will be positioned on '6' in the second line. On the other hand, if you

position the cursor on '3' in the first line by moving the cursor and then press j

then the cursor will be positioned on '3' in the second line.

The 'curswant' value in the return list of getcurpos() is used for this functionality.

Regards,

Yegappan

[vim-dev ML]

vim9scriptsetline(1, 'some text')exe "norm! V\e"echom getpos("'>")

>
> [0, 1, 2147483647, 0]
>
> Otherwise, we have to fix it like this:
>

> vim9scriptsetline(1, 'some text')exe "norm! V\e"var pos: list<number> = getpos("'>")
> pos[2] = col([pos[1], '$'])echom pos

>
> [0, 1, 10, 0]
>
> As an example, this is what the vim-exchange plugin has to do here

> <https://github.com/tommcdo/vim-exchange/blob/17f1a2cc0d009cfd7f0dcda06dd0f017fcc1c70b/plugin/exchange.vim#L292-L294>

> .
>
> If it can't be changed because it would break the compatibility with
> existing legacy Vim scripts, maybe we could limit this change to Vim9
> scripts?
>
>
>

—
You are receiving this because you are subscribed to this thread.

Reply to this email directly, view it on GitHub, or unsubscribe.

[Yegappan Lakshmanan]

Hi,

On Fri, Mar 5, 2021 at 6:46 AM lacygoill <vim-dev...@256bit.org> wrote:
>
> Interestingly enough, getpos() is affected but not getcharpos():
>
> vim9script
> setline(1, 'some text')
> exe "norm! V\e"
> echom getpos("'>")
>
> [0, 1, 2147483647, 0]
>
> vim9script
> setline(1, 'some text')
> exe "norm! V\e"
> echom getcharpos("'>")
>
> [0, 1, 9, 0]
>
> Which seems inconsistent.
>

Yes. This needs to be fixed. The getcharpos() function should return the
same value for column as getpos() in this case.

- Yegappan

[vim-dev ML]

—
You are receiving this because you are subscribed to this thread.

Reply to this email directly, view it on GitHub, or unsubscribe.

[Bram Moolenaar]

I think it's fine that getcharpos() returns the character index of the last character in the line. Returning a large number isn't helping. In case the script needs to know the position is actually "beyond end of the line" then getpos() can be used. Thus it's actually useful to have the two function return something different.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.