Yegappan wrote:
> > > Currently the prop_add_list() function doesn't support adding multiple
> > > virtual text properties. This functionality is useful when applying
> > > the inlay hints reply received from a LSP server.
> >
> > What is against calling prop_add() for each one?
>
> When adding a large number of text properties for inlay hints to a
> source file with many lines, calling prop_add() multiple times may not
> be efficient.
>
> > prop_add_list() is intended to add the same type of property and a list
> > of positions. I don't expect you want to add the same text in a list of
> > positions? Unless it's some kind of error or marker.
>
> When adding the text properties for inlay hints, the text will be
> different for each position.
>
> > > Should we extend the prop_add_list() function to support the "text"
> > > value in the second argument? The second argument (list of items)
> > > needs to support the following:
> > >
> > > [{lnum}, {col}, {end-lnum}, {end-col}, "text"]
> > >
> > > Should we make the "text_align", "text_padding_left" and "text_wrap"
> > > properties common to all the text properties or support a dict for the
> > > list element:
> > >
> > > [{lnum}, {col}, {end-lnum}, {end-col}, {'text': value, 'text_align':
> > > value,
> > > 'text_padding_left':
> > > value, 'text'wrap': value}]
> >
> > This quickly gets complicated, since depending on what you are adding
> > some fields will be the same for all properties and some will be
> > different. I doubt the complexity is justified by calling one function
> > for multiple text properties instead of calling prop_add() for each one.
> >
> > Is there a virtual text property with several fields that are the same
> > (padding, align, etc.) and only differ in position and text?
>
> No. The LSP specification for inlay hints is at:
>
> https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#inlayHint
>
> The padding is specified for each inlay hint item.
It also mentions a tooltip. I suppose we don't support that (yet).
Since this is an optimization, and the choices for implementation are
not directly clear, we should do this later perhaps. Using prop_add()
now should make clear how it works, even when it's a little bit slower.
Perhaps we might actually want to make it work better before making it
more efficient.
--
Keep America beautiful. Swallow your beer cans.
/// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/20221128112728.B47F71C0A61%40moolenaar.net.
