Re: Completion script for the ctags program

["Daniel Shahaf" <d.s@daniel.shahaf.name>]

Aaron Schrab wrote on Wed, 03 Mar 2021 23:28 +00:00:
> The completion for that *does* include all of those options. Yes, all of 
> that does make it quite verbose, but that can also be the case even 
> without that type of dynamic option names (I'm mainly thinking of curl 
> here).

FWIW:


% git -c <TAB>
zsh: do you wish to see all 288 possibilities (73 lines)? 

That's basicaly a hardcoded list, though I think it does look in `git
config --list` too for wildcard instances and in-house options.


% rsync --<TAB>
zsh: do you wish to see all 450 possibilities (151 lines)? 

Static list.


% git co <TAB>
zsh: do you wish to see all 605 possibilities (165 lines)? 

Based on repository contents.  Uses tags for sectioning.


% curl -<TAB>
zsh: do you wish to see all 661 possibilities (221 lines)? 

Static list.


% gcc -<TAB>
zsh: do you wish to see all 2495 possibilities (833 lines)? 

Static list.  It's long because all -Wfoo/-fbar/-mbaz arguments are
treated as first-class options.  I suppose that may want to be changed.

> I still think that having the completion options actually usable 
> as-is is still better than requiring the user to edit the completion 
> results. It would likely be even better in this case if the language 
> portion could be treated more as the argument to an option, and so the 
> language list would only be presented after the prefix was already 
> selected.

That's what pws proposed and I independently implemented.  Try the _f
function I posted.

There's --<lang>-foo options too (with the replaceable part first), and
there's «--foo-<lang> bar» as two words, but that's solvable.

> But I'd also say that even a completion script which generates those 
> options in need of editing would still be an improvement over nothing.

*nod*

Cheers,

Daniel