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 doesn't cause a
> > different change item. You can see "lnum" and "end" are not the same
> > here, meaning that this line might be changed.
>
> Bram - that makes total sense, thanks very much for your patience.
>
> One further issue I'm seeing relates to how undos are processed.
>
> Now with the following:
>
> function EchoChanges(bufnr, start, end, added, changes)
> redir >> /tmp/listener.log | echom getbufline(a:bufnr, 0, "$")
> a:changes | redir END
> endfunction
> call listener_add("EchoChanges")
>
> loaded via -u, with an initial file of:
>
> Line 1
> Line 2 #
> Line 3
> Line 4 #
> Line 5
> Line 6 #
>
> and then executing the following commands:
>
> :g/#/d
> u
>
> I see the following log line for the global command (which makes sense):
>
> ['Line 1', 'Line 3', 'Line 5'] [{'lnum': 2, 'col': 1, 'added': -1,
> 'end': 3}, {'lnum': 3, 'col': 1, 'added': -1, 'end': 4}, {'lnum': 4,
> 'col': 1, 'added': -1, 'end': 5}]
>
> And then the following sequence as a result of the undo:
>
> ['Line 1', 'Line 3', 'Line 4 #', 'Line 5', 'Line 6 #'] [{'lnum': 4,
> 'col': 1, 'added': 1, 'end': 4}]
> ['Line 1', 'Line 2 #', 'Line 3', 'Line 4 #', 'Line 5', 'Line 6 #']
> [{'lnum': 3, 'col': 1, 'added': 1, 'end': 3}]
> ['Line 1', 'Line 2 #', 'Line 3', 'Line 4 #', 'Line 5', 'Line 6 #']
> [{'lnum': 2, 'col': 1, 'added': 1, 'end': 2}]
>
> Now I'm guessing the undo is being processed step-by-step (so to
> speak) in reverse.
>
> So the first and second lines look wrong, because they appear to show
> the buffer already has the "next" undo applied.
>
> Again, apologies if (as is likely) I'm missing something obvious.
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...
--
|
Ceci n'est pas une pipe.
/// 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/201905162012.x4GKCGPB010443%40masaka.moolenaar.net.
For more options, visit https://groups.google.com/d/optout.
