From: Daniel Shahaf <d.s@daniel.shahaf.name>
To: zsh-workers@zsh.org
Subject: Re: clang completion
Date: Mon, 09 Jul 2018 10:19:53 +0000 [thread overview]
Message-ID: <1531131593.2733334.1434424536.2320A844@webmail.messagingengine.com> (raw)
In-Reply-To: <3925.1531085647@thecus>
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. :))
prev parent reply other threads:[~2018-07-09 10:20 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-30 8:34 Eitan Adler
2018-07-07 20:57 ` Matthew Martin
2018-07-08 6:40 ` Daniel Shahaf
2018-07-08 12:40 ` Oliver Kiddle
2018-07-08 14:02 ` Eric Cook
2018-07-08 21:34 ` Oliver Kiddle
2018-07-09 10:19 ` Daniel Shahaf [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1531131593.2733334.1434424536.2320A844@webmail.messagingengine.com \
--to=d.s@daniel.shahaf.name \
--cc=zsh-workers@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).