mbbill
Make diff window load asynchronously
On very big diffs (e.g. an external-tool changes the whole file/buffer on a very long file, e.g. reformatting the code), the entire editor can freeze for several minutes. Perhaps a “loading diff” message could be displayed until it is finished loading it asynchronously.
I’m running into this problem when trying to open undotree in a clang-formatted version of vulkan.hpp, an 80,000 line file (saved as a different file, of course). I open it for reference, but want it to be more readable, so I use an external C++ formatter. Then, when I want to glance at my undo history, to make sure I haven’t done anything else, Vim freezes for ~5 minutes.
Yeah, I know, I need to set the buffer to noma ro and probably manually delete my undo history once I’ve got it how I want it. It’d be nice to not have to lose my history, though. Also, I’m sure there’s plenty of cases where someone still needs to edit the file. They might be bad use cases, but it’s not up to undotree to punish bad coding practices with long waits :).
Both Vim and Neovim now support asynchronous execution of code. They have different implementations, though, since it was added to Neovim first. I believe there is a plugin that allows plugin writers to interface with either. You’d make async optional by detecting whether the plugin is even installed, and maybe add an option to undotree to return an error if it’s not found (so it doesn’t fail and fall back to non-async silently). Or roll your own text-replacing wrapper that detects which async calls to use.
Alternatively, you could add a scripting language dependency in a language that support async. I know Neovim has lua built-in, but I’m not 100% clear on whether lua supports async without external tools.
Yeah sometimes I run into this kind of situation too, even on some files with only couple thousands of lines I can still notice the lag. The plugin was written when async scripting wasn't a thing, so it's not quite prepared for that. Let's see if I can hack a way through it.
Also, this may be obvious, but make sure to terminate the diff-window process whenever undotree is toggled off, if possible. I’m guessing it’s probably a batch process without built-in interruption, but maybe evaluate whether a hard terminate can have any side effects.
And keep a count of how many windows are trying to create the exact same diff. Share the results, don’t terminate prematurely. Maybe you already do that, Idunno.
Some further research shows that (maybe?) Neovim’s lua engine supports multithreading, but they’re using (or will be using?) something called “libuv” for that, a cross-platform C library for async.