3 ms·

I tried this but couldn't get the completions to load. I think it's a really good idea though (much faster than zsh script completions), so hopefully soon I can

by bbkane 2y ago

I tried this but couldn't get the completions to load. I think it's a really good idea though (much faster than zsh script completions), so hopefully soon I can retry the install and either get it working or open an issue. One design aspect I do question is that completions are baked into the library. It'd be neat to have them in SQLite or something that could be updated independently (not sure how feasible that is though. I've never been any good at querying graphs like flag/command completions in SQLite).

FrozenCow 2y ago
Completions need to do arbitrary computation. A command like `git switch` needs to find what branches are available in the repository.
- bbkane 2y ago
  True, but you can represent that in the db as a a CLI invocation to run in a subshell. The big gain from something like carapace or my theoretical SQLite-based completion system is faster startup time. I had to remove zsh-completions from my shell setup as it added too much to the startup time (https://github.com/bbkane/dotfiles/blob/master/zsh/README_notes.md#install-zsh-completions---replaced-with-carapace-bin https://github.com/bbkane/dotfiles/blob/master/zsh/README_no...)
bPspGiJT8Y 2y ago
> much faster than zsh script completions I'm curious where did you get that from. Edit: I read the note in your dotfiles repo. Yes calling `compinit` on each shell invocation is going to be really slow. That's not how you're supposed to do it, you could at least add the `-C` flag to cache the completions. Ideally you'd also use `zcompile` to compile the cache to ZSH word code. This puts my completions initializing time at ~20ms on a lower/mid-end laptop. Additionally you can do the trick `fish` does and defer the initialization of completions until the first hit of Tab key, so the impact on shell startup time is exactly 0.
- bongobingo1 2y ago
  I have had this snippet in my .zshrc for years, autoload -U compinit && compinit { # Compile the completion dump to increase startup speed. Run in background. zcompdump="${ZDOTDIR:-$HOME}/.zcompdump" if [[ -s "$zcompdump" && (! -s "${zcompdump}.zwc" || "$zcompdump" -nt "${zcompdump}.zwc") ]]; then # if zcompdump file exists, and we don't have a compiled version or the # dump file is newer than the compiled file zcompile "$zcompdump" fi } &! Using `zmodload zsh/zprof`, I can see about 50% (16ms) of my start up is compinit (its about 28ms without the `zcompile`). Do you have any pointers for the "load on tab" idea? I didn't turn up any good results in DDG and LLMs were just hallucinating. BTW I believe `-C` will disable some cache checking, caching is enabled by default > To speed up the running of compinit, it can be made to produce a dumped configuration that will be read in on future invocations; this is the default, but can be turned off by calling compinit with the option -D. > ... > ... The check performed to see if there are new functions can be omitted by giving the option -C. In this case the dump file will only be created if there isn't one already.
  - bongobingo1 2y ago
    Unable to edit, but this is how I handled lazy loading the completions { # load compinit and rebind ^I (tab) to expand-or-complete, then compile # completions as bytecode if needed. lazyload-compinit() { autoload -Uz compinit # compinit will automatically cache completions to ~/.zcompdump compinit bindkey "^I" expand-or-complete { zcompdump="${ZDOTDIR:-$HOME}/.zcompdump" # if zcompdump file exists, and we don't have a compiled version or the # dump file is newer than the compiled file, update the bytecode. if [[ -s "$zcompdump" && (! -s "${zcompdump}.zwc" || "$zcompdump" -nt "${zcompdump}.zwc") ]]; then zcompile "$zcompdump" fi } &! # pretend we called this directly, instead of the lazy loader zle expand-or-complete } # mark the function as a zle widget zle -N lazyload-compinit bindkey "^I" lazyload-compinit }
  - bPspGiJT8Y 2y ago
    > BTW I believe `-C` will disable some cache checking, caching is enabled by default You're right, my memory has let me down. > Do you have any pointers for the "load on tab" idea? I didn't turn up any good results in DDG and LLMs were just hallucinating. The simplest implementation would be something like bindkey ^I init_completions init_completions () { # ... init logic here ... # rebind tab to complete bindkey ^I complete-word # actually do complete the initial request zle complete-word } Edit: I see now you already figured it out, yeah that's exactly what I meant

by bbkane 2y ago

FrozenCow 2y ago

Completions need to do arbitrary computation. A command like `git switch` needs to find what branches are available in the repository.

bbkane 2y ago
True, but you can represent that in the db as a a CLI invocation to run in a subshell. The big gain from something like carapace or my theoretical SQLite-based completion system is faster startup time. I had to remove zsh-completions from my shell setup as it added too much to the startup time (https://github.com/bbkane/dotfiles/blob/master/zsh/README_notes.md#install-zsh-completions---replaced-with-carapace-bin https://github.com/bbkane/dotfiles/blob/master/zsh/README_no...)

bPspGiJT8Y 2y ago

> much faster than zsh script completions I'm curious where did you get that from. Edit: I read the note in your dotfiles repo. Yes calling `compinit` on each shell invocation is going to be really slow. That's not how you're supposed to do it, you could at least add the `-C` flag to cache the completions. Ideally you'd also use `zcompile` to compile the cache to ZSH word code. This puts my completions initializing time at ~20ms on a lower/mid-end laptop. Additionally you can do the trick `fish` does and defer the initialization of completions until the first hit of Tab key, so the impact on shell startup time is exactly 0.

bongobingo1 2y ago
I have had this snippet in my .zshrc for years, autoload -U compinit && compinit { # Compile the completion dump to increase startup speed. Run in background. zcompdump="${ZDOTDIR:-$HOME}/.zcompdump" if [[ -s "$zcompdump" && (! -s "${zcompdump}.zwc" || "$zcompdump" -nt "${zcompdump}.zwc") ]]; then # if zcompdump file exists, and we don't have a compiled version or the # dump file is newer than the compiled file zcompile "$zcompdump" fi } &! Using `zmodload zsh/zprof`, I can see about 50% (16ms) of my start up is compinit (its about 28ms without the `zcompile`). Do you have any pointers for the "load on tab" idea? I didn't turn up any good results in DDG and LLMs were just hallucinating. BTW I believe `-C` will disable some cache checking, caching is enabled by default > To speed up the running of compinit, it can be made to produce a dumped configuration that will be read in on future invocations; this is the default, but can be turned off by calling compinit with the option -D. > ... > ... The check performed to see if there are new functions can be omitted by giving the option -C. In this case the dump file will only be created if there isn't one already.
- bongobingo1 2y ago
  Unable to edit, but this is how I handled lazy loading the completions { # load compinit and rebind ^I (tab) to expand-or-complete, then compile # completions as bytecode if needed. lazyload-compinit() { autoload -Uz compinit # compinit will automatically cache completions to ~/.zcompdump compinit bindkey "^I" expand-or-complete { zcompdump="${ZDOTDIR:-$HOME}/.zcompdump" # if zcompdump file exists, and we don't have a compiled version or the # dump file is newer than the compiled file, update the bytecode. if [[ -s "$zcompdump" && (! -s "${zcompdump}.zwc" || "$zcompdump" -nt "${zcompdump}.zwc") ]]; then zcompile "$zcompdump" fi } &! # pretend we called this directly, instead of the lazy loader zle expand-or-complete } # mark the function as a zle widget zle -N lazyload-compinit bindkey "^I" lazyload-compinit }
- bPspGiJT8Y 2y ago
  > BTW I believe `-C` will disable some cache checking, caching is enabled by default You're right, my memory has let me down. > Do you have any pointers for the "load on tab" idea? I didn't turn up any good results in DDG and LLMs were just hallucinating. The simplest implementation would be something like bindkey ^I init_completions init_completions () { # ... init logic here ... # rebind tab to complete bindkey ^I complete-word # actually do complete the initial request zle complete-word } Edit: I see now you already figured it out, yeah that's exactly what I meant