Minimalist, high-performance fish prompt
MIT License
A minimalist, high-performance fish prompt with async git dirty checks that just work.
Install with Fisher:
fisher install mattgreen/lucid.fish
Initial rendering is fast enough, considering that the LLVM repo has over 361,000 commits:
~/Projects/llvm-project on master •
❯ time fish_prompt
~/Projects/llvm-project on master •
❯
________________________________________________________
Executed in 14.05 millis fish external
usr time 5.96 millis 2.10 millis 3.86 millis
sys time 6.87 millis 2.54 millis 4.33 millis
lucid fetches most git information synchronously. This minimizes the amount of flicker induced by prompt redraws, which can be distracting. This initial time encompasses:
This information is memoized to avoid re-computation during prompt redraws, which occur upon completion of the git dirty check, or window resizes.
lucid_dirty_indicator
: displayed when a repository is dirty. Default: •
lucid_clean_indicator
: displayed when a repository is clean. Should be at least as long as lucid_dirty_indicator
to work around a fish bug. Default:
(a space)lucid_cwd_color
: color used for current working directory. Default: green
lucid_git_color
: color used for git information. Default: blue
lucid_git_status_in_home_directory
: if set, git information is alsolucid_skip_newline
: if set, doesn't insert a newline before the prompt.lucid_prompt_symbol
: the prompt symbol. Default: ❯
lucid_prompt_symbol_error
: the prompt symbol when an error occurs.❯
lucid_prompt_symbol_color
: the color of the prompt symbol.$fish_color_normal
lucid_prompt_symbol_error_color
: the color of the prompt symbol when an$fish_color_normal
Each prompt invocation launches a background job responsible for checking dirty status. If the previous job did not complete, it is killed prior to starting a new job. The dirty check job relays the dirty status back to the main shell via an exit code. This works because there's only three distinct states that can result from a dirty check: dirty, not dirty, or error. Systems programming FTW!
After launching the job, the parent process immediately registers a completion handler for the job. In there, we scoop up the exit status, then update the prompt based on what was found.
The rest is book-keeping and careful coding. There may be a few more opportunities for optimization. Send a PR if you find any!
The tough problem here is keeping the execution time low, and communicating the dirty status from the job back to the parent.
Here are a few other approaches that didn't pan out:
tmpfs
filesystem available by defaultfzf
.disown
the job because it needs to collect the exit status from it.