Lazy loading segments or async execution

[maratori]

Code of Conduct

• I agree to follow this project's Code of Conduct

What would you like to see added?

I work with a large monorepo where running git status takes around 4 seconds to complete. Currently, Oh-My-Posh is not designed for handling such scenarios. To work around this, I’ve used the untracked_modes property (alternatively, ignore_status property can be used):

version: 3
blocks:
  - type: prompt
    segments:
      - type: git
        style: plain
        properties:
          untracked_modes:
            /path/to/monorepo: no

While this approach improves performance, it comes at the cost of losing some key pieces of information in the prompt.

Meanwhile, Oh My Zsh handles such cases seamlessly by leveraging an async prompt.

I propose adding similar asynchronous support to Oh-My-Posh. The key idea is as follows:

• If the execution time of a segment exceeds a configurable threshold (e.g., X milliseconds):
  • Display the prompt immediately with cached output for the slow segment.
  • Continue executing the segment in the background and update the cache when the result is ready.
  • Use the updated result from the background process in the next prompt rendering.

This enhancement, especially when combined with periodic refreshing (#5036), would significantly improve the user experience.
Additionally, it could serve as an alternative to p10k-like instant prompts (#5310).

[JanDeDobbeleer]

@maratori this is a very challenging feature as oh-my-posh isn't shell native. It can be achieved, but nowhere near easily. And unfortunately that's one of these features where I simply don't have the time until this project's funding allows me to partially quit my day job.

[maratori]

this is a very challenging feature ...

Yes, I agree.

... as oh-my-posh isn't shell native.

Can you please clarify what you mean and how it relates to this feature?

And unfortunately that's one of these features where I simply don't have the time until this project's funding allows me to partially quit my day job.

I completely understand your time constraints. Perhaps I could work on implementing this feature. However, we would need to design it first, as there are several key design decisions to address before creating a PR.

[JanDeDobbeleer]

Can you please clarify what you mean and how it relates to this feature?

@maratori as oh-my-posh' main code is written in golang and is executed as a binary, it can't just return data and keep processing. In the end, it outputs a string that need to be evaluated by the shell and therefore needs to exit. Stopping the execution because a segment's timeout constraint hits is possible, but then something else needs to be informed this happened and execute the logic async. It requires a process to constantly run shell side, which needs to understand if it still needs to render (or reset when something happens that makes it irrelevant). And, that needs to be added to every shell we support (where possible). Not easy at all.

I'll see if I can add the segment timeout function already, as that's a prerequisite to this. It might also help me understand how this could work.

[maratori]

It requires a process to constantly run shell side, which needs to understand if it still needs to render (or reset when something happens that makes it irrelevant).

I think there is another option. The main process can run exec.Command().Start() without calling Wait(). The child process takes all necessary information from git and writes it to a file. The main process will read the file next time.

This can be combined with file locks to avoid creating extra processes.

Of course, this is necessary only if sync execution takes too much time.