[vim/vim] [virtual text] The 'extends:c' character in 'listchars' is drawn at the wrong position when 'list' is enabled (Issue #10913)

20 views
Skip to first unread message

bfrg

unread,
Aug 13, 2022, 3:41:17 PM8/13/22
to vim/vim, Subscribed

Steps to reproduce

Run vim --clean test.vim -S test.vim, with

vim9script



colorscheme habamax

set list

set listchars+=extends:»

set nowrap



prop_type_add('Prop1', {highlight: 'Error'})



prop_add(3, 0, {

    type: 'Prop1',

    text: 'The quick brown fox jumps over the lazy dog',

    text_align: 'right'

})

Result: The extends:c character is drawn instead of the last character of the virtual text. In the above example it's drawn on the 'g' of 'dog'.

Screenshot
screenshot-2022-08-13_211351

Expected behaviour

In the above example, the extends:c character shouldn't been drawn at all. If the buffer line is too long and wrap is disabled, it should be drawn on the last visible buffer text and not virtual text.

I don't know what to expect when a line is too long to fit on the screen and wrap is disabled. Currently, the extends:c character is displayed, and the virtual text is not visible at all. I think this is as expected.

However, when the virtual text is not fully visible, the extends:c character is drawn on the virtual text. See the screenshot below. In my opinion, Vim should use the character for the virtual text when it doesn't fit on the screen. This is already done in other cases. The extends:c character should be reserved only when the actual buffer text doesn't fit on the screen.

screenshot-2022-08-13_213333

Version of Vim

9.0.199

Environment

Linux

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.Message ID: <vim/vim/issues/10913@github.com>

bfrg

unread,
Aug 13, 2022, 3:56:15 PM8/13/22
to vim/vim, Subscribed

In my opinion, Vim should use the character for the virtual text when it doesn't fit on the screen. This is already done in other cases.

Well, the character is shown only when wrap is enabled. It disappears with nowrap. Is this intentional?

Screenshot
screenshot-2022-08-13_215430

Example code in the screenshot:

vim9script



# This is a very long text line. This is a very long text line. This is a very long text line. 

colorscheme habamax

set nolist

set listchars+=extends:»

set wrap



prop_type_add('Prop1', {highlight: 'Error'})



prop_add(3, 0, {

    type: 'Prop1',

    text: 'The quick brown fox jumps over the lazy dog',

    text_align: 'right'

})


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/10913/1214214273@github.com>

Bram Moolenaar

unread,
Aug 14, 2022, 2:38:15 PM8/14/22
to vim/vim, Subscribed

Closed #10913 as completed via c3a483f.


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issue/10913/issue_event/7185046352@github.com>

Bram Moolenaar

unread,
Aug 14, 2022, 2:38:52 PM8/14/22
to vim/vim, Subscribed


> > In my opinion, Vim should use the `…` character for the virtual text
> > when it doesn't fit on the screen. This is already done in other
> > cases.
>
> Well, the `…` character is shown only when `wrap` is enabled. It
> disappears with `nowrap`. Is this intentional?

Yes, with 'nowrap' the text isn't really truncated, it just continues
after the end of the window, just like with normal text.

We can show the "extends" character also for virtual text, so it's clear
there is more to follow.

--
"Shoot for the moon. Even if you miss, you'll land among the stars."

/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/10913/1214428655@github.com>

Reply all
Reply to author
Forward
0 new messages