-
-
Notifications
You must be signed in to change notification settings - Fork 94
Description
groups
useruser specs at~/.config/carapace/specssystemsystem specs (not yet implemented)commoncommon completersdarwincompleters for macoslinuxcompleters for linuxunixcompleters for linux/macos/...windowscompleters for windowstermux/androidcompleters for termux?bash,fish, ... completers for shells?bridgebridged completers
selection
Specific group/variant should be selectable.
carapace tldr # default tldr completer
carapace tldr/tealdeer # tealdeer variant of tldr completer
carapace sed@unix # sed completer of unix group
carapace sed/bsd@darwin # bsd variant of sed completer in darwin group
carapace git@system # git completer of system specThis clashes with
carapace- --diff git/fish, which needs to be changed.
completers
Completers should be moved into groups.
Variants can be build using build tags in completers/{group}/{name}_completer/main_{variant}.go.
completers
├── common
│ ├── git_completer # standard completer
│ │ └── cmd
│ └── tldr_completer # completer with variants
│ ├── tealdeer
│ └── tldr-python-client
├── darwin
│ └── skhd_completer
├── linux
│ └── acpi_completer
├── unix
│ └── apropos_completer
└── windowsDocumentation should reflect which completer is included on which target os.
use single
main.goand switch on choice:
func main() {
switch choice, _ := choices.Get("tldr"); {
case choice.Match("tldr/tealdeer@common"):
tealdeer.Execute()
case choice.Match("tldr/tldr-python-client@common"):
tldr_python_client.Execute()
default:
tealdeer.Execute()
}
}actions
Needs groups as well (windows actions make no sense for linux).
Variants could just be another subpackage as name clashes aren't an issue like completers.
Core macros should ideally support all os:
- GOOS file extension (update: can't be due to
forceallbuild tag) - build tags
- runtime checks
- path checks for different information sources depending on what is installed (e.g.
ipvsnmclivs ...)
Documentation should reflect which macro works on which target os.
probably better to focus on runtime check so that a develop binary can be built that includes
allcompleters.
likely needs similargroupstructure like the completers. duplicated prefixes are fine, but the full macro name needs to be unique across groups (checked during build).
specs/overlays
Specs don't necessarily need groups. Local ones target a specific os anyway.
Also spares users migration effort (at least for now).
Only for syncing with a remote repo and shell specific completers it could be relevant.
specs
├── custom.yaml
└── tldr
├── tealdeer.yaml
└── tldr-python-clientchoice
Instead of bridges.yaml specific variants should be selectable via carapace --choice name/variant@group
choices
├── tldr # tldr/tealdeer
├── sed # sed@darwin
└── dkms # dkms/zsh@bridgeuse simple text files with the command as name (avoids unnecessary and slow parsing)