From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17046 invoked by alias); 9 Jul 2018 10:20:00 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: List-Unsubscribe: X-Seq: 43154 Received: (qmail 21398 invoked by uid 1010); 9 Jul 2018 10:20:00 -0000 X-Qmail-Scanner-Diagnostics: from out1-smtp.messagingengine.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(66.111.4.25):SA:0(-2.6/5.0):. Processed in 2.324588 secs); 09 Jul 2018 10:20:00 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, SPF_HELO_PASS,T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.1 X-Envelope-From: d.s@daniel.shahaf.name X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= daniel.shahaf.name; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=8Uc4kY qgeqdMuwzqvpRScuVn0KEP0VOfXlQHE2Mu4c4=; b=Lz8Yn039oHm0I9qccon3vf +ABTvRxUF0NkRapAfJX75iSg7eq4zcGxUlIAWmFGUEQLRA+6G62uedpyRTJbbxrd VdJ2KKhMKiKAiQ7Gr//hOKdREbZuDBghcfFvwgBOqkLXoKSqT8wx5MHkendm1iia R5SHy4bjxdTC6o+LHJJjzOK1McEcwBi10hYSPA9QSWRrMMqFrOYq9gGyn3civr5j nJA6ah3paXyoVcoPR6s23g0cIFXidvMRRliYAZpj6FtFloTNo/HbOH5CWC80PSu4 czm3sbAxhPxxaSczjA0va7LtcBxO6GVHolacfd7OBiACiKg+F+iUCUEwn64qu7OQ == DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=8Uc4kY qgeqdMuwzqvpRScuVn0KEP0VOfXlQHE2Mu4c4=; b=KEJsuPeug+Apt//ygH+zEv MCLjslM3TsiDxHp5RuGw5aPVJtnyyN3MtpigdF75bvzfBoAe1XLKR3BSDA0n24pM jKC4gVS6s4jd20KW3FZby/B0v+u4vhpN4ao60vOCPagRhRtCVzW7eDIe726RyyNv Apdosr+14T7iD7aefjTsiYxxc7Hmxfnpz77oNBKpxkQIGr9PrsjMXBhXYcmFkkC1 FhI+1JwFVtmJBEi9rSmsQ99Fe6yN9kscUU3mese4z8n71yx8/krlEusrjhqshQDw Tcg987mYmomjSeLFpntgRduSpY71gUKGD4Q0vI9Ex8RvTaPf+X3HMP2kbu4yU6ig == X-ME-Proxy: X-ME-Sender: Message-Id: <1531131593.2733334.1434424536.2320A844@webmail.messagingengine.com> From: Daniel Shahaf To: zsh-workers@zsh.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-0d8ea36c References: <20180707205750.GA62923@CptOrmolo.darkstar> <20180708064008.rkjzh2h376kqehs6@tarpaulin.shahaf.local2> <2431.1531053655@thecus> <3925.1531085647@thecus> Subject: Re: clang completion In-Reply-To: <3925.1531085647@thecus> Date: Mon, 09 Jul 2018 10:19:53 +0000 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. :))