Display "subprocess running" indicator for shell_pipe, shell_insert_output, et al.

[nathan-at-least]

Problem

Long running child processes completely freeze the UI, and it's not immediately apparent what's happening. The end result is ok, and everything behaves as "it should", but it may not be clear to users that everything is operated correctly because it's indistinguishable from the UI crashing into a frozen state.

User Story

I just ran ! to insert the output of a command. It so happened, the command was cargo run <options>. What happened was the entire hx interface froze for quite some time. I deduced this was because it was waiting for cargo to build and for the command to run. It turned out I was right, but I didn't have any immediate way to know if I was right. (The cargo run child took about 45s to complete, but it's easy to imagine child commands that could take much longer.)

Suggested Improvements

I propose a range of solutions that I assume go from simplest to implement to hardest (due to UX complexity):

Simplest Improvement: Running Indicator

When launching a child process, freeze all user input to hx while also displaying a spinner that shows that the command is indeed running and hx is awaiting output. Because the spinner keeps updating, it helps users distinguish between "the child is still running" vs "I've hit some bug that caused hx to completely hang".

Extra credit: the status could also display the command and args in addition to the spinner.

Intermediate Improvement: Cancellation

Same as above, but allow a user to cancel the action (maybe with ESC). Make sure to let users know this is possible, perhaps in the status bar it says "Press ESC to cancel" or somesuch. Cancelling aborts the command and kills the child process. This could be really important if the user accidentally executes a command that will never terminate (e.g. cat - for shell_insert_output, see #4154).

Complex Improvement: Per-Buffer "Waiting-on-Child" State

All commands except commands which modify the buffer are active: users can navigate around the file, search, go-to-definition, edit other buffers, open new files, open menus, etc…

Challenges:

• Can we clearly display a "Waiting-on-Child" indicator on a per-buffer basis?
• If they navigate around the Waiting-on-Child buffer, there would need to be a read-only cursor/selection-like display for where the child command is operating (shell_pipe, shell_insert_output, etc…).
• Some actions might attempt to modify the buffer in an indirect manner. For example, what if they execute :reload-all ? Is there a way to clearly indicate to a user that this command failed for only the "Waiting-on-Child" buffers but succeeded for other buffers?

My Preference

Given that I'm not too familiar with hx implementation, it feels like the Intermediate Solution might be the most feasible: it's easy to understand from a UX perspective, and I assume the implementation wouldn't be too complex and would fit into the current code architecture without being too disruptive.

Related Tickets

I searched for similar issues. I found a bunch that are related but not quite about a "running spinner" request:

• Terminal freezes after shell_insert_output or shell_append_output and a command that reads from stdin #4154 is about hanging when the child is waiting for input. The Intermediate Improvement above with the cancel feature would seem to fully address this, IMO.
• Helix editr gets stuck when :sh sh #3524 might also be addressed by this improvement. It's about :sh. I'm less certain (I've not used that command yet).
• fix: terminal freezing on shell_insert_output #4156 I think addresses the two above if I understand correctly? Or it's at least related. It doesn't directly address the issue in this ticket, though, because it's only about children expecting stdin, whereas this is about all children, some of which happen to take a long time to run.

[gabydd]

Some more discussion here #1060 I think your intermediate idea is the plan hopefully for all tasks that can potentially block the ui

[pascalkuthe]

there is also already an implementation: #6436 (based on my work I mentioned in that issue)