[vim/vim] Conceal on steroids (Issue #10537)
Francisco Lopes
Is your feature request about something that is currently impossible or hard to do? Please describe the problem.
Many editors provide support for virtual textual decorations: text which isn't authored, but is displayed alongside real content, for many many kinds of purposes. The main late use case is inlay hints, a well known feature of IDEs, that's currently being pushed forward by the Language Server Protocol. rust-analyzer, clangd, and possibly other servers implement it, but Vim can't take advantage of it at all, because it has no means to intermingle these virtual text hints with real text content.
Describe the solution you'd like
Vim already provides one feature that seems to touch this subject, but in a very strict way, which is the conceal feature. From what I could gather, it seems the ideal route to attain NeoVim-like virtual text, VSCode-like inlay hints, while at the same time augmenting Vim's conceal powers, would be to take the conceal feature and generalized its concept somehow. In which ways? For example, current conceal can only conceal text for a single cchar, we need to be able to conceal text for another text, conceal zero-length matches to make virtual text "appear", not solely "replace"/conceal, have conceal grouping (so it can be configured by purpose independently, "virtual text" group concealcursor won't affect "inlay hints" concealcursor nor Vim's native conceal's concealcursor), have conceal by position, not just by regex.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
- neovim/neovim#9496 (comment)
- fannheyward/coc-rust-analyzer#177 (comment)
- fannheyward/coc-rust-analyzer#177 (comment)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Yegappan Lakshmanan
vim-dev ML
On Tue, Jun 7, 2022 at 5:49 PM Francisco Lopes ***@***.***>
wrote:
> *Is your feature request about something that is currently impossible or
> hard to do? Please describe the problem.*
>
> Many editors provide support for virtual textual decorations: text which
> isn't authored, but is displayed alongside real content, for many many
> kinds of purposes. The main late use case is inlay hints, a well known
> feature of IDEs, that's currently being pushed forward by the Language
> Server Protocol. rust-analyzer, clangd, and possibly other servers
> implement it, but Vim can't take advantage of it at all, because it has no
> means to intermingle these virtual text hints with real text content.
>
>
> Vim already provides one feature that seems to touch this subject, but in
> a very strict way, which is the conceal feature. From what I could
> gather, it seems the ideal route to attain NeoVim-like virtual text,
> VSCode-like inlay hints, while at the same time augmenting Vim's conceal
> powers, would be to take the conceal feature and generalized its concept
> somehow. In which ways? For example, current conceal can only conceal
> text for a single cchar, we need to be able to conceal text for another
> text, conceal zero-length matches to make virtual text "appear", not solely
> "replace"/conceal, have conceal grouping (so it can be configured by
> purpose independently, "virtual text" group concealcursor won't affect
> "inlay hints" concealcursor nor Vim's native conceal's concealcursor),
> have conceal by position, not just by regex.
>
> A clear and concise description of any alternative solutions or features
> you've considered.
>
>
> - neovim/neovim#9496 (comment)
> <https://github.com/neovim/neovim/pull/9496#issuecomment-1149278996>
> - fannheyward/coc-rust-analyzer#177 (comment)
> <https://github.com/fannheyward/coc-rust-analyzer/issues/177#issuecomment-618883195>
> - fannheyward/coc-rust-analyzer#177 (comment)
> <https://github.com/fannheyward/coc-rust-analyzer/issues/177#issuecomment-618883195>
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Francisco Lopes
Thanks Yegappan, I tried to find something similar in the issue tracker but failed.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Bram Moolenaar
> **Is your feature request about something that is currently impossible
> or hard to do? Please describe the problem.**
>
> Many editors provide support for virtual textual decorations: text
> which isn't authored, but is displayed alongside real content, for
> many many kinds of purposes. The main late use case is inlay hints, a
> well known feature of IDEs, that's currently being pushed forward by
> other servers implement it, but Vim can't take advantage of it at all,
> because it has no means to intermingle these virtual text hints with
> real text content.
>
>
> Vim already provides one feature that seems to touch this subject, but
> in a very strict way, which is the `conceal` feature. From what I
> could gather, it seems the ideal route to attain NeoVim-like virtual
> text, VSCode-like inlay hints, while at the same time augmenting Vim's
> `conceal` powers, would be to take the `conceal` feature and
> generalized its concept somehow. In which ways? For example, current
> able to conceal text for another text, conceal zero-length matches to
> make virtual text "appear", not solely "replace"/conceal, have conceal
> grouping (so it can be configured by purpose independently, "virtual
> text" group `concealcursor` won't affect "inlay hints" `concealcursor`
> position, not just by regex.
of syntax highlighting. Adding syntax rules to match a specific file
position is not a great solution.
Something similar to text properties, which can be added and removed
individually, is a much better match. Intead of using a popup the text
would "push other text to the side". This is complicated, but it's
possible.
--
If "R" is Reverse, how come "D" is FORWARD?
/// 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.
You are receiving this because you commented.
Francisco Lopes
Conceal is not a great match for this functionality, because it is part
of syntax highlighting. Adding syntax rules to match a specific file
position is not a great solution.
Wholly agree with that, implementation-wise, it's not exactly right, but I can't stop thinking that borrowing some concepts from conceal would be very good to have on this new feature, like concealcursor-like setting, which controls when concealing happens or not, depending on cursor focus on given line (I guess that configurable "unhide" would need to be extended when going over virtual texts in specific, not just when focusing the line).
On NeoVim discussion side a doubt was brought up about what exactly to do with cursor position inside virtual text (and extended concealing of large text for another). I have suggested that Vim already have some behavior at that with current conceal, and that one way to implement position in this context is to view every cursor position as positioning (every position is conceptually attained as if there's a motion: when leaving and entering back a buffer, last position is taken as a motion from start of text, then every cursor position taken while not leaving the buffer will happen by going from some original position to the new one). FYI, I'll copy it here:
The question is what we do with cursor positions within.
Current conceal already has to have an answer to that. At least a partial one (the cursor solely walks real text behind the scenes, while teleporting over the virtual one, either by getting stuck for a while if it's shorter, or jumping if it's larger):
This is my attempt at modeling more detailed behavior/description at this, and what I think might make a reasonable trade off:
- For this to work, we have to consider what's reasonable to have while moving the cursor, no just its static position. To have a simpler model of that, we should stop viewing the text as 2D, and model it simply as 1D (a long string with a lot of
\nin the middle). Given that, we can now simply think of any cursor motion as either going forward or back in the file (right or left in the long string it is), even though while editing we in fact use two dimensions, underneath it's not.
Now consider in the following diagram, the line above is the text displayed (containing a mix of virtual and REAL content), while the line below is just the corresponding REAL text content, | is the current cursor position and ⇒ separates the whole text states in each step:
- In
ABxyGH,xyconcealsCDEF(shorter virtual text hides larger real one):
An extreme case would have an empty string in place ofWarp from left: |ABxyGH ⇒ A|BxyGH ⇒ AB|xyGH ⇒ ABx|yGH ⇒ ABx|yGH ⇒ ABx|yGH ⇒ ABxy|GH ⇒ ABxyG|H ⇒ ABxyGH| |ABCDEFGH⇒A|BCDEFGH⇒AB|CDEFGH⇒ABC|DEFGH⇒ABCD|EFGH⇒ABCDE|FGH⇒ABCDEF|GH⇒ABCDEFG|H⇒ABCDEFGH| Warp from right: ABxyGH| ⇒ ABxyG|H ⇒ ABxy|GH ⇒ ABx|yGH ⇒ AB|xyGH ⇒ AB|xyGH ⇒ AB|xyGH ⇒ A|BxyGH ⇒ |ABxyGH ABCDEFGH|⇒ABCDEFG|H⇒ABCDEF|GH⇒ABCDE|FGH⇒ABCD|EFGH⇒ABC|DEFGH⇒AB|CDEFGH⇒A|BCDEFGH⇒|ABCDEFGHxy, in which case, when the cursor travels through the "invisible tunnel", it would get stuck for a while to go either fromBtoGor fromGtoB(while it's jumping the real chars behind). It's the use case of conceal. - In
ABwxyzEF,wxyzconcealsCD(larger virtual text hides shorter real one):
An extreme case would have a zero-length match instead ofWarp from left: |ABwxyzEF⇒A|BwxyzEF⇒AB|wxyzEF⇒ABw|xyzEF⇒ABwxyz|EF⇒ABwxyzE|F⇒ABwxyzEF| |ABCDEF ⇒ A|BCDEF ⇒ AB|CDEF ⇒ ABC|DEF ⇒ ABCD|EF ⇒ ABCDE|F ⇒ ABCDEF| Warp from right: ABwxyzEF|⇒ABwxyzE|F⇒ABwxyz|EF⇒ABwxy|zEF⇒ABwx|yzEF⇒A|BwxyzEF⇒|ABwxyzEF ABCDEF| ⇒ ABCDE|F ⇒ ABCD|EF ⇒ ABC|DEF ⇒ AB|CDEF ⇒ A|BCDEF ⇒ |ABCDEFCD, in which case, the cursor travels through the "discontinuity", it would jump over from eitherBtoEor fromEtoB, 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).
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.
Francisco Lopes
Seems worth to mention that Emacs has support for this. As I'm no Emacs user, I have no idea what's the actual behavior, regarding the cursor, or whether it works in terminal.
See: https://emacs-lsp.github.io/lsp-mode/page/lsp-rust-analyzer/#inlay-hints.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Igbanam Ogbuluijah
Dunno if this counts, but there's a plugin which may do this already. It may pay to checkout how it's done there. coc-pyright has "type hints" which look very much like — if not is exactly — what's being asked for here. Now I don't know if this is coming from coc.nvim or from the pyright extension itself, but it's there. Here's a video showing you what it looks like
https://user-images.githubusercontent.com/390059/192875921-ca652bed-e30e-4a98-a5df-6aaaf1f0dfd2.mov
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.
Francisco Lopes
Thanks for the input @igbanam. It's surely coming from coc-pyright but I'm not sure whether it's still available at this moment, and probably is only working on Vim9 through Vim9 text properties?
@fannheyward could you chime in to confirm what's happening, because on NeoVim that above in the video is only available at the end of the line through NeoVim's virtual text feature, I don't have a Vim9 setup ready to check coc-pyright behavior on that at the moment, but despite that it would be good to have an official word on how that is working on Vim9 if still available.
@igbanam yes the feature might be almost exactly the same, but not quite because in your video the hint doesn't vanish when the cursor is at the line of the hint, like conceal can be configured for in many ways. So, the hint is removed when you enter insert mode and comes back with you exit it? That's not shown in the video, exactly when it's displayed and hidden while editing.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Francisco Lopes
It looks like it was implemented here fannheyward/coc-pyright#797.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Francisco Lopes
Oh right, it's a quite new Vim9 feature, discussion with commit ref can be found here: neoclide/coc.nvim#4090.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Francisco Lopes
Given it has been implemented, I think this issue here should be reviewed for closing or something.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Christian Brabandt
Closed #10537 as completed.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Christian Brabandt
let me close it then. If you notice any problems, please open a new issue. Thanks.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Francisco Lopes
The only problem is what's already mentioned above, as this implementation shouldn't follow the same rationale of Conceal, so, there's quite probably no flexibility at hiding/unhiding the text hint, like one can do with Conceal (conceal at diverse modes, etc). If that's a Won't Fix given it's unrelated to text properties, fine, but still sad because I've already hit a thread where a random person asks for the same functionality.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.