Fork me on GitHub

@snoe Did you ever figure out more stuff about :undojoin? I googled and came across your StackOverflow questions (with no answers) 😄


Specifically, always calling it is bad, since calling it after an undo or redo destroys the undo history. But I haven't been able to figure out how to determine when not to call it.


IIRC I feel that I ran into a wall with it, I don't think it was possible to do what I wanted.


I suspect as much. I sent an e-mail to the vim list, but nobody's responded.


There's a way to get the current undo history. But it seems to indicate our current position incorrectly anyway.


Vim events are kind of a mess 😞


yeah I was looking forward to the nvim api delta events but that seemed to be stuck in it's own quagmire


I cannot imagine what the nvim people must do to add something like that. It's like, "first, read all the code. Then document the 300 cases we need to change to produce a consistent API."


I was poking at Vim and Neovim's job control stuff and channels, and it seems like it should be possible to do the async nrepl stuff without python for both. @dominicm


Opening a socket and communicating asynchronously. I mean, it's kind of what async.vim does.


But, the Vim8 docs allows for connecting and specifying an asynchronous callback.


My (less thorough) investigation of Neovim suggests that the same can be done.


Vim8 prefers JSON and Neovim prefers msgpack, but both indicate you can do raw if you want.


I don't really want to write a parser in vimscript. But it could be done, yeah.


I had enough pain writing one for ANSI codes


Heh. Would you accept one if I did it? I'm not sure if I'm serious yet, just checking.


If you can prove it works, sure. Having taken mine through a lot of failure cases now, that would be important. I just got generative testing working and I'm finally quite happy that the exceptions have stopped. We should be careful to look at the performance impact too, but we could always have a fallback approach.


@eraserhd it might be faster if lua had a way to do sockets? Just a thought.


@snoe re: delta events, you mean the thing that’s supposed to notify the consumer of incremental changes to a buffer?


@jebberjeb maybe? It's been over a year since I looked seriously. But like @eraserhd said there's so many ways a buffer can change in vim and the more accurately you can inform parinfer, the better.


I’m really hoping that will be the way to find out without polling. I guess if you listen to redraw events, and you set the ext-options map to exclude menu, command line, etc from that, you know something visible on the screen that you might care about changed.


But that’s just the entire visible UI really, nothing to do with buffers or anything.


I think that PR might make the next release based on comments there.