The title of this PR means something awesome!
Could you share screenshots of how it looks like, as you work on this? 🙏

TODO item: set wd=50 rdb=compositor,nodelta number relativenumber

added options: virt_lines_above and virt_lines_signcol

TODO: cannot display virt_lines below last line. (above first line works, need to scroll up tho after adding)

Please correct me if I'm wrong, but I think this could be used for the use-case mentioned in #9496 (comment) (linked Reddit post: https://www.reddit.com/r/neovim/comments/ieh7l4/im_building_an_image_plugin_and_need_some_help/).

I imagine it would enable plugins such as https://github.com/heapslip/vimage.nvim and https://github.com/edluffy/hologram.nvim to make virtual space for displaying images without tampering with the buffer. Is this assumption correct?

As I understand it, yes. On the same line, it would also be quite helful in https://github.com/dccsillag/magma-nvim in order to have output windows which do not cover any of the buffer text.

@dccsillag Would be amazing! Also can be useful for VCS tools.

Can someone give an example for this
I tried lua vim.api.nvim_buf_set_extmark(0, ns, 5, 0, {virt_lines={{{'line 1', 'String'}}, {{'line 2 ', 'ErrorMsg'}, {'text','LineNr'}}, }}) (from bfredl above)
but got this

@max397574 make sure that ns is a valid variable that holds a namespace id :)

@max397574

:lua ns = vim.api.nvim_create_namespace('virtline_testing')
:lua vim.api.nvim_buf_set_extmark(vim.fn.bufnr(), ns, 2, 1, {virt_lines={{{'line 1', 'Comment'}}, {{'line 2;', 'Comment'}}}})

Note the double braces on the virt_lines stuff.

Cursor movement seems to remove the virtual lines for me. Does anyone else also experience this?

Update: doesn't happen with nvim -u NONE. Probably an autocommand then, but probably an issue -- I'll try to single it out.

Weird, I can't reproduce it anymore.

I have tested with echodoc. But it seems broken with native popup menu.

When I select the candidate

The original popup menu with text.

@Shougo is there a branch somewhere with the actual code? otherwise I cannot reproduce.

I have pushed code.

I have tested echodoc master branch with the config.

let g:echodoc#type = has('nvim') ? 'virtual_lines' : 'popup'
call echodoc#enable()

I have tested it with ddc.vim neco-vim echodoc with Vim script editing.

that... sounds like a lot of stuff to setup and many layers to debug. maybe I will check it later.

Cursor movement seems to remove the virtual lines for me. Does anyone else also experience this?

Update: doesn't happen with nvim -u NONE. Probably an autocommand then, but probably an issue -- I'll try to single it out.

I am also encountering this issue. This happens very frequently with vim-matchup's matchparen feature. If I run autocmd! matchup_matchparen to remove matchup_matchparen autocmds, then it happens less frequently, but it still sometimes happens.

I'm not sure about a better place to ask this, so I'll just do that here: do you plan on supporting some sort of cursor navigation into virtual lines?
To make it a bit more concrete consider a table of contents rendered as virtual lines. Moving the cursor into them would allow some "jump to heading under cursor" action to be programmed.

the whole point of virtual lines is that they don't rly are there so you can't move the cursor on them I think?

But it would be really nice. Because it would be an easy way to have temporary text.

Pretty sure the whole point of virtual lines is to have lines that aren't in the buffer. That means that things such as LSP won't pick up on them, and they can't be accidentaly saved. This is mostly orthogonal to allowing the cursor to be on them.

I absolutely get that! But having some way of moving onto them would be nice. Kinda like gj and gk work on wrapped lines it would be awesome to have some similar function to support moving into virtual lines (they don't need to be mapped to anything by default but having this functionality available for a plugin dev to leverage and map to would be awesome)

That sounds more like embedding a sub-buffer into a window (so that the cursor can take positions within the embedded buffer). which might be something we can do, but separate from virtual text/lines as such (which are rather UI elements like statusline/whatevercolumn)

That sounds more like embedding a sub-buffer into a window

Hm interesting 🤔 So do you think like a borderless floating window which gets inserted between lines? That would probably also deal with buffer changes better than the current virtual lines because they get removed after a buffer change. However, if (for example) the ToC were in a yet entirely different buffer that could arguably be handled a bit better..

These sorts of attached floating windows sound really cool! They could help out in a lot of scenarios. If the item is treated as an isolated buffer then it gives a lot of freedom to the programmer without having to be worried about messing up the buffer it's contained in :)