Hi Bram,
> So do you think that the last callback should in fact be two callbacks?
Thanks for your fix in v8.1.1389 and all the work before that for
listener_add - I've landed initial support for delta-based updates in
govim:
> Hmm, that is not right, since after this change the second line would be
> the terminating quote.
Indeed, but we don't ever see the buffer in that state.
> I see. So one would argue that the second change makes the "end" lnum of
> the first change invalid, thus the changes would need to be
Paul Jolly wrote:
> > Up to you. You can merge the changes into one, keeping the lowest
> > changed line number and the total deleted/added lines, or you can deal
> > with each change separately.
>
> I'm not sure I see how the change can be handled separately (without
> carrying forward
Paul Jolly wrote:
> Thanks for your other response. Not sure whether my message below came
> through.
>
> It seems I'm going to have to do a bit more work on the list of
> changes that comes through.
>
> In the example, I think I actually need to collapse the two changes
> into a single one
Thanks very much.
> Up to you. You can merge the changes into one, keeping the lowest
> changed line number and the total deleted/added lines, or you can deal
> with each change separately.
I'm not sure I see how the change can be handled separately (without
carrying forward position changes)
Paul Jolly wrote:
> Thanks for your patience with this!
>
> > So the first list are the lines in the buffer?
>
> Yes, correct.
>
> > > ['const x = ``'] [{'lnum': 1, 'col': 11, 'added': 0, 'end': 2}, {'lnum':
> > > 1, 'col': 12, 'added': 0, 'end': 2}]
> >
> > Here you type the first
Thanks for your other response. Not sure whether my message below came through.
It seems I'm going to have to do a bit more work on the list of
changes that comes through.
In the example, I think I actually need to collapse the two changes
into a single one with added = 2.
Then do a pass over
Paul Jolly wrote:
> > Here you type Enter twice.
>
> Not sure if it's significant, but I only hit enter once. The plugin makes
> the second change here.
It matters in the sense that there is no screen redraw in between.
If you would have typed really fast then the same thing would have
>
> Here you type Enter twice.
Not sure if it's significant, but I only hit enter once. The plugin makes
the second change here.
--
--
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
Thanks for your patience with this!
> So the first list are the lines in the buffer?
Yes, correct.
> > ['const x = ``'] [{'lnum': 1, 'col': 11, 'added': 0, 'end': 2}, {'lnum': 1,
> > 'col': 12, 'added': 0, 'end': 2}]
>
> Here you type the first backtick, and the plugin adds the second
>
Paul Jolly wrote:
> > Good luck. Let me know when something doesn't work properly, we can
> > still adjust the functionality for a week or so. Well, once you use it
> > we should probably not change it anymore.
>
> Hi Bram,
>
> Good news: I have delta based updates from govim -> gopls
Paul Jolly wrote:
> > You are right, the changes are flushed before adding one that changes
> > the line numbers, but the text has already changed. I'll see how that
> > can be fixed...
>
> Thanks very much for the quick fix; I've confirmed it's working.
>
> Thanks again for your patience; I
> You are right, the changes are flushed before adding one that changes
> the line numbers, but the text has already changed. I'll see how that
> can be fixed...
Thanks very much for the quick fix; I've confirmed it's working.
Thanks again for your patience; I think I now have a sufficient
Paul Jolly wrote:
> > > Again, apologies if I'm missing something obvious here.
> >
> > This is not inserting a line but splitting a line. There could be text
> > after the insertion point, which moves to the next line when pressing
> > Enter. In your case there might be nothing, but that
> > Again, apologies if I'm missing something obvious here.
>
> This is not inserting a line but splitting a line. There could be text
> after the insertion point, which moves to the next line when pressing
> Enter. In your case there might be nothing, but that doesn't cause a
> different change
Paul Jolly wrote:
> > The help is wrong, it should say "line above which".
> > Of course we could change the implementation, but it would be an exception.
>
> Ah, if it's "line above which" then I think there is a problem with
> the following sequence:
>
> iasdf
>
> which gives:
>
>
> The help is wrong, it should say "line above which".
> Of course we could change the implementation, but it would be an exception.
Ah, if it's "line above which" then I think there is a problem with
the following sequence:
iasdf
which gives:
[{'lnum': 1, 'col': 1, 'added': 0, 'end': 2}]
Paul Jolly wrote:
> > I'll make a patch that does this, please check it out.
>
> Hi Bram - I've only spotted one potential issue working with v8.1.1333.
>
> Using the following vimrc
>
> function EchoChanges(bufnr, start, end, added, changes)
> redir >> /tmp/listener.log | echom a:changes
> I'll make a patch that does this, please check it out.
Hi Bram - I've only spotted one potential issue working with v8.1.1333.
Using the following vimrc
function EchoChanges(bufnr, start, end, added, changes)
redir >> /tmp/listener.log | echom a:changes | redir END
endfunction
call
> I'll make a patch that does this, please check it out.
Thanks, Bram. I'll only properly get a chance to look this weekend.
As you said this function is quite low level. Thinking about govim,
what I'm going to want is the lowest cost means of translating a
callback to the listener into an LSP
I wrote:
> > Paul Jolly wrote:
> >
> > > > Yesterday I sent out patch 8.1.1321 which adds listener_add().
> > > > This makes it possible to find out about text changes and possibly
> > > > update text properties or anything else.
> > >
> > > Hi Bram - this is fantastic, thanks. I look forward
I wrote:
> Paul Jolly wrote:
>
> > > Yesterday I sent out patch 8.1.1321 which adds listener_add().
> > > This makes it possible to find out about text changes and possibly
> > > update text properties or anything else.
> >
> > Hi Bram - this is fantastic, thanks. I look forward to giving
Paul Jolly wrote:
> > Yesterday I sent out patch 8.1.1321 which adds listener_add().
> > This makes it possible to find out about text changes and possibly
> > update text properties or anything else.
>
> Hi Bram - this is fantastic, thanks. I look forward to giving this a try with
>
> Understood. One relatively easy way to handle this is to handle the changes
> in reverse, i.e. by iterating through the list backwards. But I think this
> requires that the changes themselves be non-overlapping.
I actually misunderstood what you said here, so please ignore the question :)
> Yesterday I sent out patch 8.1.1321 which adds listener_add().
> This makes it possible to find out about text changes and possibly
> update text properties or anything else.
Hi Bram - this is fantastic, thanks. I look forward to giving this a try with
https://github.com/myitcv/govim and
Yesterday I sent out patch 8.1.1321 which adds listener_add().
This makes it possible to find out about text changes and possibly
update text properties or anything else.
The current implementation is quite low-level. That makes it possible
to see exactly what text changed. Also for something
26 matches
Mail list logo
