[vim/vim] weird cursor position when inserting character at the end of long line which is about to wrap (Issue #9884)
lacygoill
Steps to reproduce
Run this shell command:
vim -Nu NONE -S <(tee <<'EOF'
vim9script
&signcolumn = 'yes'
&showbreak = '+ '
var leftcol: number = win_getid()->getwininfo()->get(0, {})->get('textoff')
repeat('x', &columns - leftcol - 1)->setline(1)
'second line'->setline(2)
feedkeys('AA')
EOF
)
The first line does not wrap, and the cursor is drawn on the second line of screen which is also the second line of the buffer:
second line
^
Expected behavior
The first line does wrap, and the cursor is drawn on the second line of screen which is also the first line of the buffer:
+ |
^
cursor
Version of Vim
8.2 Included patches: 1-4495
Environment
Operating system: Ubuntu 20.04.4 LTS
Terminal: xterm
Value of $TERM: xterm-256color
Shell: zsh 5.8
Screenshot
Additional context
As soon as we insert one more character, the cursor is drawn in a correct position; i.e. on the first line of the buffer. But the correction makes it look like the cursor jumped from the second line of the buffer to the first one, which is distracting. In reality, the cursor never left the first line.
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
Although it looks strange, especially because of the 'showbreak' value, it was intentionally made to work this way.
This happens because there isn't any text to wrap yet.
Without 'showbreak' it looks better, it's like the cursor has wrapped from the previous line.
Let's see if we can ignore 'showbreak' in this specific case.
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
lacygoill
This happens because there isn't any text to wrap yet.
OK, but for me the cursor is meant to indicate where the next character will be inserted. And the next character won't be inserted where the cursor is currently drawn (inside the sign column).
I would argue that it would be more intuitive for the line to wrap immediately, to take into account the next character which is about to be inserted.
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
> > This happens because there isn't any text to wrap yet.
>
> OK, but for me the cursor is meant to indicate where the next
> character will be inserted. And the next character won't be inserted
> where the cursor is currently drawn (inside the sign column).
the sign column, it looks like you are inserting in front of the next
line. Without the sign column that already happens, but there really
isn't another place for the cursor then.
> I would argue that it would be more intuitive for the line to wrap
> immediately, to take into account the next character which is about to
> be inserted.
pressing Esc the line disappears.
--
hundred-and-one symptoms of being an internet addict:
158. You get a tuner card so you can watch TV while surfing.
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///