general virttext can be understood as the the inverse of conceal: we shift vcols to the right rather than the left on the screen.

👍

Should virttext be truncated, or should the line be allowed to grow vertically due to virtual text?

Would "grow vertically" be a similar effect as diff "filler lines"?

Would "grow vertically" be a similar effect as diff "filler lines"?

Ah that's true. So there already is logic for managing vertical space from changes outside the buffer itself, we should follow that then.

Would it be feasible to generalize conceal to full strings rather than single characters from these changes?

Yes. It would be feasible to replace any character range with any string (within a line). The question is what we do with cursor positions within.

Bump and usecase report:

rust-analyzer provides a compelling use case for this, see fannheyward/coc-rust-analyzer#177 (comment).

Currently only chainingHints are provided due to this limitation.

Bump, usecase is adding empty virtual lines to draw images.

https://www.reddit.com/r/neovim/comments/ieh7l4/im_building_an_image_plugin_and_need_some_help/
Can we please, please, please get this?

Bumping this again with another usecase: displaying titles of linked notes inline.
fiatjaf/neuron.vim#23

This would be really useful!

Willing to put $200 bounty on this. I know that’s likely not enough, but I want to provide the most incentive I can currently afford and see if others feel alike.

One more usecase - pull request comments/in-nvim review: #15331

@Ciel-MC we accept contributions. Please send a pull request if you'd like to implement this.

An extreme case would have a zero-length match instead of CD, in which case, the cursor travels through the "discontinuity", it would jump over from either B to E or from E to B, as there's no real text between it, only virtual. It's the use case of inlay hints (and virtual text, at the end of the line).

After #20130 is merged, NeoVim has got Vim's solution for inlay hints. Right after first usages I'm spotting usability issues that relate to the quote above. Movement over a buffer with intermixed virtual text is affected by it, using w to jump over words, for example, often may land at the start of a virtual text that comes before the start of the real text, the text that's going to be changed on cw is far from cursor, after the virtual head. One can't edit virtual text, just the real text, so why the cursor jumps to the virtual text instead of the actual text? It's an implementation detail that's affecting editing in counter-intuitive ways.

Ideally, while editing code, virtual text would be passed-through, popping in and out of existence meanwhile real content changes. If that's not attained, then we have what we have now, virtual text confusingly positing as real text.

so why the cursor jumps to the virtual text instead of the actual text?

I don't see this happening at all. Is there a screenshot or perhaps a small video?

@bfredl (click to expand resolution):

clangd is in use, by means of coc-clangd.

Hmm this is not the behavior I get. But perhaps it is affected by options, like cpoptions which are not the default here.

A couple questions on the above discussion:

• @oblitum drew a distinction between concealing and inlaying. I'm not sure I understand the significance of the distinction or what this means exactly. At a high level, why does it make sense to think about virtual text occupying horizontal space in terms of the conceal feature / as "anti-conceal"? There's some mention of this benefiting from existing features / offering a more consistent experience - what does that look like concretely?

• Would virtual text occupying horizontal space be allowed to contain newlines? For example, given

def foo(|)

where | is the cursor, one might want to virtually display a completion as

def foo(|
  arg1,
  arg2,
)

where the lines with arg1, and arg2, appear as virtual text but the closing ) does not, and this would all still be only one actual line.