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, and the plugin adds the second
> > backtick.
>
> Yup, this looked right to me.
>
> > > ['const x = `', '', '`'] [{'lnum': 1, 'col': 12, 'added': 1, 'end': 2},
> > > {'lnum': 2, 'col': 1, 'added': 1, 'end': 2}]
> >
> > Here you type Enter twice. The first time the existing line is split,
> > so you get lnum = 1 and end = 2. The second time a line is inserted, so
> > you get lnum = 2 and end = 2. You get two entries with "added" equal to
> > one, thus two lines have been added, that is also correct.
>
> The problem (or likely my misunderstanding) is that I get both of
> these in the same callback, i.e. they both see the buffer in the state
> shown, hence neither "sees" the change in line 3.
Well, it depends on what you want to do with them. The line numbers are
correct and the text lines are correct for those line numbers.
If you have a number of changes in the same line, you only get the final
state though, not all the text states in between. And I assume that's
fine.
> To provide this in context (perhaps what I should have done from the start).
>
> What I'm doing in response to these callbacks is gathering the
> affected lines, adding them to each of the changes, and passing on the
> lots to govim (to save roundtrips).
>
> for l:change in a:changes
> if l:change.added < 0
> let l:change.type = "deleted"
> else
> if l:change.lnum != l:change.end
> let l:change.type = "changed"
> let l:change.lines = getbufline(a:bufnr, l:change.lnum,
> l:change.end-1+l:change.added)
> elseif l:change.added > 0
> let l:change.type = "inserted"
> let l:change.lines = getbufline(a:bufnr, l:change.lnum,
> l:change.lnum+l:change.added-1)
> endif
> endif
> endfor
>
> Or for the second entry in the change list, do I need to move lnum
> "forward" by the number of lines added before?
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.
Your loop has a clear problem, that if you get two changes, one deleting
a line and one adding a line, then the l:change.type will get the last
change type, which depends on the ordering, so that won't work. The
easiest would be to deal with each change separately. Thus just before
the "endfor".
> > Perhaps it's confusing that when a line is inserted, the "lnum" is the
> > line above which it is inserted. Imagine doing "O" on a line. Doing
> > "o" on the previous line has the same effect, thus you get the same line
> > numbers.
>
> I _think_ I have this one sorted ;-) But depending on your answer
> above that might also prove to be a wrong assumption!
It is unrelated, it's just that you might expect a different line number
when inserting a line.
--
hundred-and-one symptoms of being an internet addict:
8. You spend half of the plane trip with your laptop on your lap...and your
child in the overhead compartment.
/// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ 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/201905221850.x4MIoUvr015509%40masaka.moolenaar.net.
For more options, visit https://groups.google.com/d/optout.
