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:
https://github.com/myitcv/govim/commit/ad260329614442948d653c270343cbf
> 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 flus
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 positi
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 w
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) in
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 backtick,
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 th
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
happene
>
> 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 http://
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
> backtic
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 largel
> 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 largely working.
But there appears to be
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 handl
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 does
> > 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:
>
> [{'lnum'
> 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}]
[{'ln
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 listener_
> 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 de
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 this
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
> https://g
> 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 :)
Now
> 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 gopls.
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
27 matches
Mail list logo