Run shell commands asynchronously

[sarah-quinones]

this pr adds a basic implementation of run-async-shell-command (alias = 'async-sh') which runs the shell command asynchronously while discarding its output. this is helpful when the command can run for a long time and its output doesn't matter (or can be piped to a file if needed), and it may be desirable to do so without blocking the editor

[pascalkuthe]

I think the behavior of :sh should be changed instead of adding a new command. There is no reason for :sh to block the editor as it doesn't insert any text into the buffer.

I general I want to move helix to a point where we never block the editor on IO unless absolutely necessary (pasting from the clipboard, or piping into the editor, in which case there should be a timeout) so this would be a nice enhancement 👍 You can just replace the call to shell_impl with shell_async_impl and await the result in async callback we already have (you would just need to move the output.is_empty check and setting the editor status into the callback

[sarah-quinones]

i changed it so that sh is non blocking. and displays the output once everything's done. is there a way to make it so that the output is displayed incrementally as new lines appear?

[pascalkuthe]

is there a way to make it so that the output is displayed incrementally as new lines appear?

Yes but that's possible but would require larger changes and would probably be a bit tricky to implement. You would need to split shell_impl_async into a subfunction that just returns the spawned process without waiting for it to finish. so that it just returns the process (and the input_task if necessary). You can then use the ChildStdout reader to asyncrounsly read lines. Currently the Markdown popup used for rendering shell output can't change it's content so you would need a way to do that. The best way would probably to just use an Arc<Mutex<String>> and to push to that String from the background task whenever a full line has been read to a buffer. You probably need to add an AtomicBool into the Arc that is set to true by the rendering thread as so as it reaches the Mutex that is checked reguarlarly by the background thread so that it doesn't try to lock the Mutex while rendering (which would block rendering) and give up the lock if already acquired.

It's definitely a nice improvement I have thaught about before but a bit more work. You can decide yourself If you want to do it in this PR or a seperatly.

[sarah-quinones]

i think doing it in a separate PR is best. i don't think im familiar with the codebase enough to accomplish that yet. but i'll be giving a try once i find some time

[pascalkuthe]

LGTM, just one minor nit 👍

[pascalkuthe]

I don't think we really need a helper for this. I don't foresee this pattern really being used in other commands and it's simple enough to just inline into the callsite

[sarah-quinones]

i pushed a commit that inlines it, and updated the commit message

[pascalkuthe]

LGTM now, nice usability improvement 👍

[David-Else]

I think I have hit an example where async is not doing what I would like:

Z = { Z = [":sh kitty @ close-window --match title:^hx- --ignore-no-match", ":wq" ], Q = ":q!" }

ZZ does not close the kitty window, but if I remove ":wq" it does. I assume it is a problem with the delay in the kitty command, any idea of a solution? Thanks!

[nikaro]

I run into a smiliar issue than @David-Else, i'm trying to do this:

[keys.normal.space]
t = [":sh theme-sync", ":config-reload"]

The config is reloaded before my command terminates.