Skip to content

support variants #3118

@rsteube

Description

@rsteube

groups

  • user user specs at ~/.config/carapace/specs
  • system system specs (not yet implemented)
  • common common completers
  • darwin completers for macos
  • linux completers for linux
  • unix completers for linux/macos/...
  • windows completers for windows
  • termux/android completers for termux?
  • bash, fish, ... completers for shells?
  • bridge bridged 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 spec

This 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
└── windows

Documentation should reflect which completer is included on which target os.

use single main.go and 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 forceall build tag)
  • build tags
  • runtime checks
  • path checks for different information sources depending on what is installed (e.g. ip vs nmcli vs ...)

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 all completers.
likely needs similar group structure 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-client

choice

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@bridge

use simple text files with the command as name (avoids unnecessary and slow parsing)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions