[vim/vim] Virtual text to the right of the line that fits exactly on screen causes that line and all lines below it not to be displayed (Issue #12213)

Marius Gedminas

unread,

Mar 31, 2023, 9:41:07 AM3/31/23

to vim/vim, Subscribed

Steps to reproduce

When vim-ale puts a bit of virtual text after the end of the line, and the length of the actual text exactly matches the window width, Vim gets confused and hides the entire line (and usually the lines below it):

This requires :set nowrap and is a bit easier to see with :set display=.

I've managed to reproduce this or something very like this (I don't see the @ characters, but the text itself disappears):

Create a repro.vim with

40vsplit
0put ='here is some text more text even *more*:'
put ='  more text!'
put ='  more text!'
put ='  more text!'
put ='  more text!'
set nomodified " make :qa work for convenience
set nowrap
set display=
set list listchars=extends:>
call prop_type_add("bug", {"highlight": "Error"})
call prop_add(1, 0, {"type": "bug", "text": "# virtual text that is longer than the actual text", "text_padding_left": 1})

Run vim --clean -S repro.vim

Observe:

Expected behaviour

This is what things look like when the window is one character wider than the text:

and in my synthetic example:

Version of Vim

9.0.1392

Environment

OS: Ubuntu 22.10
Terminal: gnome-terminal 3.46.2 using VTE 0.70.0
$TERM: xterm-256color
Shell: bash

Logs and stack traces

No response

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

Marius Gedminas

unread,

Mar 31, 2023, 9:45:37 AM3/31/23

to vim/vim, Subscribed

Forgot to mention one possibly related detail: the listchars extends character (>) is not drawn when the window width exactly matches text width, despite there being virtual text after it. If I increase the size of the window, the > re-appears. I'm not sure if I should be filing a separate bug for it, or if it's caused by the same underlying drawing bug.

—
Reply to this email directly, view it on GitHub.

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

bfrg

unread,

Mar 31, 2023, 2:43:42 PM3/31/23

to vim/vim, Subscribed

Just wanted to mention that the error remains with nolist:

vim9script
# 0123456789 0123456789 0123456789 0123456789

:45vsplit
set nowrap
prop_type_add('test', {highlight: 'Error'})
prop_add(2, 0, {
    text_align: 'after',
    text: 'The quick brown fox jumps over the lazy dog',
    type: 'test'
})

Run vim --clean test.vim -S test.vim.
Result: The content in the left split is not displayed correctly.

Screenshot:

After pressing CTRL-W > (or CTRL-W <) everything is as expected:

—
Reply to this email directly, view it on GitHub.

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

Dylan Thacker-Smith

unread,

Mar 27, 2024, 8:55:04 AM3/27/24

to vim/vim, Subscribed

Forgot to mention one possibly related detail: the listchars extends character (>) is not drawn when the window width exactly matches text width, despite there being virtual text after it. If I increase the size of the window, the > re-appears. I'm not sure if I should be filing a separate bug for it, or if it's caused by the same underlying drawing bug.

This behaviour had already changed before I took a look at the issue, it now already shows the extends character on the truncated line in the provided test case, even without my proposed fix (#14307)

—
Reply to this email directly, view it on GitHub.

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

Christian Brabandt

unread,

Mar 28, 2024, 6:54:45 AM3/28/24

to vim/vim, Subscribed

Closed #12213 as completed via b6fac4d.

—
Reply to this email directly, view it on GitHub.

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

Reply all

Reply to author

Forward