Re: clang completion

[Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>]

Oliver Kiddle wrote on Sun, 08 Jul 2018 23:34 +0200:
> Eric Cook wrote:
> > > This sort of design tends to follow from the way bash programmable
> > > completion is designed. I'd far prefer to have clear options for listing
> > > all warnings, languages, options etc. Those potentially have wider uses.
> > > 
> >
> > Do you mind further expanding upon this? so people considering this option
> > can be directed to a location of why this may not be desired for other shells.
> 
> For a useful link to which we can refer people, some tidying and editing
> work might be needed.
> 
> In bash, a function adds matches to the COMP_REPLY array. You can get
> bash to do matching with compgen -W but clang has saved you the trouble:
> clang --autocomplete='-fv' will only list options starting with -fv.
> Firstly, we don't want matching done for us that way.

... because we (zsh) let the user configure how to do matching.  The
user can decide whether completion would be case-sensitive or not.  The
number of knobs available for the user to tweak is large.  The user may
even implement his own matching process as a special shell function.
Thus, it is not feasible for the command run to do matching for zsh.

> gcc has various forms of --help that provide a good example of the sort
> of thing I was suggesting, e.g. gcc --help=target, --help=params and
> --help=warnings. Perhaps an additional option could force these into a
> more parsable match:description format with no headers/footers or word
> wrapping.
> 
> Where it is useful for a command to parse the command-line for us, I'd
> be happy with getting back a list of tags and offsets for how much of
> the prefix and suffix should be ignored. So after -std= it might for
> example, return standards:5:0 to tell you to complete standards after
> stripping 5 characters of prefix and 0 of suffix. For the general case,
> it might return more than one of these. We'd want all the tags
> documented and they might be something like "files" that we already
> complete some other way. The interface for that should not do weird
> stuff with commas like clang. One idea would be to pass the word offset
> followed by the character offset of the cursor followed by all words
> (prefix and suffix). But, I'm not sure how well something like that
> would really work in practice.

Cheers,

Daniel
(Oliver, thanks for your reply elsethread; I have yet to fully digest it. :))