Multiple text properties with 'text_align' right render on separate lines

[puremourning]

Steps to reproduce

hi SpellBad gui=underline cterm=underline
call prop_type_add( 'MyErrorText', #{ highlight: 'SpellBad' } )
" Used for padding - without error highlight
call prop_type_add( 'MyPadding', #{ highlight: 'Normal' } )
call prop_add( 6, 0, #{ type: 'MyPadding', text: '   ', text_wrap: 'wrap', text_align: 'right' } )
call prop_add( 6, 0, #{ type: 'MyErrorText', text: 'This is the error', text_wrap: 'wrap', text_align: 'right' } )

• vim --clean test.vim test.vim
• See that the 'This is the error' is rendered on the following line.

I'm not sure this is strictly a bug (maybe a feature request?) but wanted to share the use case in case it's worth changing. I'm trying to implement some "padding" so that a diagnostic message rendered on the right of the screen is separated from the text, but without it having the "Error" formatting applied to it (in this case, SpellBad with underline). The error formatting applying to the 'text' attribute looks weird. Here's the above where the padding is just added as the text (like the docs suggest):

hi SpellBad gui=underline cterm=underline
call prop_type_add( 'MyErrorText', #{ highlight: 'SpellBad' } )
" Used for padding - without error highlight
" call prop_type_add( 'MyPadding', #{ highlight: 'Normal' } )
" call prop_add( 6, 0, #{ type: 'MyPadding', text: '   ', text_wrap: 'wrap', text_align: 'right' } )
call prop_add( 6, 0, #{ type: 'MyErrorText', text: '    This is the error', text_wrap: 'wrap', text_align: 'right' } )

Expected behaviour

I was hoping to use an 'invisible' padding property with a different highlight such that the "padding" is inserted with Normal highlight, then the error with SpellBad highlight but all on the same line without the second property going on to a new line (unless it required for wrapping).

One option might be to have a pad-left and/or 'pad-right' option in the dict for virtual text properties; that would cover the use case and might be simpler to implement than "arbitrary" stacking.

Version of Vim

9.0.193

Environment

macOS arm64

Logs and stack traces

No response

[puremourning]

PS. There is a workaround which is to make the 'padding' property "after" rather than "right":

hi SpellBad gui=underline cterm=underline
call prop_type_add( 'MyErrorText', #{ highlight: 'SpellBad' } )
" Used for padding - without error highlight
call prop_type_add( 'MyPadding', #{ highlight: 'Normal' } )
call prop_add( 6, 0, #{ type: 'MyPadding', text: '   ', text_wrap: 'wrap', text_align: 'after' } )
call prop_add( 6, 0, #{ type: 'MyErrorText', text: 'This is the error', text_wrap: 'wrap', text_align: 'right' } )

so this isn't a huge deal.

[brammool]

We can add a "padding" argument to the text property. It would add that many spaces, without highlighting, to the left of the text.

[puremourning]

I have a use-case for padding on the right side too, where you have an inlay hint. In LSP, they have bools to say if the UI should render padding on left/right. so if it's simple enough to have padding-left/padding-right or for padding to be a list [ left, right ], that would be nice if it's not too much harder to implement.

https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_inlayHint

	/**
	 * Render padding before the hint.
	 *
	 * Note: Padding should use the editor's background color, not the
	 * background color of the hint itself. That means padding can be used
	 * to visually align/separate an inlay hint.
	 */
	paddingLeft?: boolean;

	/**
	 * Render padding after the hint.
	 *
	 * Note: Padding should use the editor's background color, not the
	 * background color of the hint itself. That means padding can be used
	 * to visually align/separate an inlay hint.
	 */
	paddingRight?: boolean;
```

[brammool]

I have a use-case for padding on the right side too, where you have an inlay hint. In LSP, they have bools to say if the UI should render padding on left/right. so if it's simple enough to have padding-left/padding-right or for padding to be a list [ left, right ], that would be nice if it's not too much harder to implement.

I do not like supporting virtual text without highlighting, because it is not clear that it is virtual text. So long as the text is after the line, it is (more or less) clear that it is not part of the text, it comes after where the cursor goes with "$". Inside the text, moving the cursor left-right will jump over the padding, without being clear why one can't put the cursor there. Or why "x" doesn't remove it (like when moving over a Tab). It should work to use separate virtual text items with slightly different highlighting, e.g. a grey background, to make clear there is a kind of gap here. We could add properties to the virtual text for this, with a padding size and highlighting, but that complicates things. So far I think it looks OK with just spaces at the start and/or end of the virtual text, using the same highlighting. I'm thinking of function argument names and types.

…

-- Not too long ago, unzipping in public was illegal... /// 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 ///

[puremourning]

That's a solid reasoning, and yeah I agree.

I've been playing with multiple properties (one for left-pad, one for argument name, one for right pad), and I've noticed an interesting redraw case when changing properties on WinScrolled: the screen is redrawn (sometimes) in between 2 calls to prop_add, (or perhaps prop_delete) meaning that the virtual text moves around on the screen.

https://asciinema.org/a/WqzLSJiXU5kToyF762w6HQjGZ

I tried to capture with writedelay to show what was being drawn, but it seems not to happen in that case. I think it might be to do with background timers, but I could be way off on that.

I haven't yet been able to narrow it down to a repro case, yet but will let you know if I do. I also can't rule out a bug in my code here of course!

[puremourning]

ignore the above, there was a problem in my code. It's interesting though - the problem was I was creating too many properties and not removing them correctly. Strange manifestation, but easily solved on my end. I think we can close this with the fix in 9.0.199.