Re: clang completion

[Oliver Kiddle <okiddle@xxxxxxxxxxx>]

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.

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.

Oliver