UI should be async

[Alphare]

Hi, I realize that this issue is asking for a significant change in the codebase, but the sooner it's done, the easier the switch will be.

This would add the ability to keep the UI responsive while loading slower commands, and do background loading more easily.

Have you already thought about this?

[vamolessa]

Hey! I did not think hard about this, no.

However, how do you see it working? I mean, when I run some command (say, push), we need to wait for it to finish before we can run another command. Maybe with it, we could add some kind of spinner feedback?

Also, how could we deal with multiple outputs when running more than one command at the same time? Right now, after each command is triggered, verco wait for it to finish and then print its output so you know what is on screen is from the command you just run.

[Alphare]

Some actions can take a long time, especially with big repos. It's the VCS's job to ensure that locks are in place where needed. I see no reason why I shouldn't look at the log or the diff of a certain revision during a long pull/push.

I believe that VCS GUIs in general should use separate buffers for different commands and offer the information as soon as possible while indicating that said information may be stale in an obvious manner while reloading said info in the background.

[vamolessa]

So, for each command, we can cache its previous result and display that immediately.

At the same time, the command runs in the background (we may display some 'waiting for completion feedback' in the mean time).

When it resolves, we display the new output if we're still on the same 'tab' (ie, we did not try to run another command), otherwise, we just update the command cached output.

This should make the UI more responsive and may allow other improvements like #17

[Alphare]

Yes, that's exactly it. Finer UI details such as allowing to force reload in case we ever screw things up should be considered during implementation, of course.

Have you taken a look at smol? It's the runtime behind async-std now. I'm not certain if a full async-std would be needed or simply smol with a few primitives.

[Alphare]

https://github.com/fdehau/tui-rs

Maybe we could consider switching to TUI, keeping crossterm as a backend? It provides a nice async-first API and good design primitives. The switch itself shouldn't be too much work.

[vamolessa]

Just merged responsive-ui to master. It uses working threads in the background to execute children processes and then the ui thread updates itself when it sees that something finished.

With this change, I had to remove the hash shortcut thing. However, we already had plans to substitute it for something better. I may work on that next.

So, I'm closing this.