Hi, On Sat, Jul 31, 2021 at 1:08 AM Pontus Leitzler <[email protected]> wrote:
> I'm not sure if it's really a practical issue as such? As far as I can > tell it's plenty fast enough. > > Aside: the biggest issue I ran in to is that length can't span multiple > lines and that I need to do some stuff to transform byte offsets to > line/col; there's probably more overhead in all of that. > > At any rate, the downside of the proposed API is that you first need to > group properties by type, rather than by position. I think the latter is > probably more common? > > Thanks @arp242 <https://github.com/arp242> for your comment! Let me add > some more context. Even though performance is key when doing syntax > highlighting, it isn't necessarily the pure invokation speed of one vs. > multiple calls the proposal aims to improve. > > The govim plugin uses a vim channel to communicate, so each call renders a > network roundtrip & JSON parsing. We also want to express that each call > should be surrounded with try/catch if we, for example, would like to > suppress E964/E966 (invalid col/line). > > Those things are mostly implementation details of my particular use case, > and we already batch multiple calls into a single roundtrip for example. > > I do however think that having a prop_add_list() make sense for others as > well. As my example above shows there is a lot of redundant information > that needs to be passed as arguments when using a single call per text > property. If you, instead of applying highlights to the visible lines only, > applies highlights to the entire buffer you could end up with several > kilobytes of redundant "type":"foobar","bufnr":1,"id":2. > > The arguments to prop_add_list() doesn't have to be as suggested above, > the goal is just to have something that better fits the purpose of using > text properties as syntax highlight replacement. In that use case you often > get a bunch of highlights to apply to a single buffer where there is a > limited set of different types. > > That maybe answers your question too @yegappan > <https://github.com/yegappan>: > > If the argument to the new prop_add_list() function is a List of the > arguments accepted by prop_add(), will that work? > > Such list would be an improvement to the number of calls, but we would > still have all the overhead of having to define multiple type, bufnr and > id for example. I don't think it brings enough benefits to be worth > adding a new call? (i.e. prop_add_list()). > > > If prop_add_list() takes a List of the prop_add() arguments, then you can use a single call to set all the text properties (instead of multiple calls to prop_add_list() in your example). So I think the reduction in the number of calls is a better tradeoff than passing less information per call. Regards, Yegappan -- -- 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/CAAW7x7%3DPcu9pfsba6T1dAr8AGWMiLg1-U6dQnnTqYAKvBSY_gQ%40mail.gmail.com.
