Follow-up from the shell-completion work (#2096): complete the argument values of verb flags. Today verb-flag values fall back to filename completion. The completion engine already records (verb, flag) at a value position, so this is "fill in a provider," not new architecture. Three sub-problems with different cost/value:
1. Enumerated keyword values (easy, high value, no I/O)
Flags whose argument is a closed set defined in Miller's code:
stats1 -a, merge-fields -a → accumulator names (sum mean count median p50 stddev …), from stats1AccumulatorInfos in pkg/transformers/utils/stats1_accumulators.gostats2 -a → linreg-ols r2 cov corr …step -a → stepper names (delta shift shift_lag rsum ewma …)- a few smaller fixed sets (
case, format-values, …)
Mirrors the existing main-flag enum completion (-i/--ifs); needs a small (verb, flag) → values table plus getters so the lists don't drift. Low risk.
2. Field names (high value, architecturally thorny)
cut -f <TAB>, sort -nf <TAB>, stats1 -g <TAB> → the data's column names. Requires reading the input header, which runs into:
- The input file is often not on the command line yet (typed after the verb, or piped on stdin) → nothing to read.
- When present, the filename can be before (
--from) or after the verb → must scan the whole line.
- Must honor format flags (
--icsv/--itsv/--ijson, custom separators, implicit header) → partially invoke the reader factory; adds I/O + latency.
- Comma-separated lists (
cut -f a,b,<TAB>) are one shell word → parse past the last comma and suppress already-chosen fields.
Should be gated so it never errors/slows a TAB when no readable file is discoverable. Medium-large; deserves its own design.
3. Plain strings / filenames (nothing to do)
head -n, sample -k → arbitrary; put -f, tee, join -f → filenames (already handled by the file fallback).
Suggested order
Ship #1 first (cheap, safe). Treat #2 as a separate effort. #3 needs nothing.
Lower priority.
Follow-up from the shell-completion work (#2096): complete the argument values of verb flags. Today verb-flag values fall back to filename completion. The completion engine already records
(verb, flag)at a value position, so this is "fill in a provider," not new architecture. Three sub-problems with different cost/value:1. Enumerated keyword values (easy, high value, no I/O)
Flags whose argument is a closed set defined in Miller's code:
stats1 -a,merge-fields -a→ accumulator names (sum mean count median p50 stddev …), fromstats1AccumulatorInfosinpkg/transformers/utils/stats1_accumulators.gostats2 -a→linreg-ols r2 cov corr …step -a→ stepper names (delta shift shift_lag rsum ewma …)case,format-values, …)Mirrors the existing main-flag enum completion (
-i/--ifs); needs a small(verb, flag) → valuestable plus getters so the lists don't drift. Low risk.2. Field names (high value, architecturally thorny)
cut -f <TAB>,sort -nf <TAB>,stats1 -g <TAB>→ the data's column names. Requires reading the input header, which runs into:--from) or after the verb → must scan the whole line.--icsv/--itsv/--ijson, custom separators, implicit header) → partially invoke the reader factory; adds I/O + latency.cut -f a,b,<TAB>) are one shell word → parse past the last comma and suppress already-chosen fields.Should be gated so it never errors/slows a TAB when no readable file is discoverable. Medium-large; deserves its own design.
3. Plain strings / filenames (nothing to do)
head -n,sample -k→ arbitrary;put -f,tee,join -f→ filenames (already handled by the file fallback).Suggested order
Ship #1 first (cheap, safe). Treat #2 as a separate effort. #3 needs nothing.
Lower priority.