From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7407 invoked by alias); 8 Jul 2018 21:34:18 -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: 43153 Received: (qmail 25581 invoked by uid 1010); 8 Jul 2018 21:34:18 -0000 X-Qmail-Scanner-Diagnostics: from park01.gkg.net 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(205.235.26.22):SA:0(-1.4/5.0):. Processed in 1.883383 secs); 08 Jul 2018 21:34:18 -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=-1.4 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_NONE,SPF_PASS,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.1 X-Envelope-From: SRS0=Q5UD=JY=yahoo.co.uk=okiddle@bounces.park01.gkg.net X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | X-Virus-Scanned: by amavisd-new at gkg.net Authentication-Results: amavisd4.gkg.net (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.co.uk X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1531085648; bh=oGTVSZhzv8New7kNbEDoczf96WaEIcFW422AkFsgKKQ=; h=From:References:To:Subject:Date:From:Subject; b=uAezah7E31wECyKccQtCjRDFbDmqH1Km/Sq9EaLIXaEgvId4zuCgKIQ6EkGIA4nSnY2K71jqOBH84AhIWa23lLiUoO1MDQ2d+7wIla/tcvDvWDRa8RYwweh+PpGxkYScxbIkvFMo0ojJnt08dRQ60ZfdJFdc4Wq2gbwFq32r/PaFULxDBUYlDUUfeQJ02bh4G4EKuN2MRD8IiC+ArV1RH596y8OUylvvInzdoT2IxM65iuhkpdvEIPtsSUhCAusuTQERMFQ40P50hfHcJw9Zb+/yueOS5ut6Mil7SrvQrDV84kDBenetEkuatvDXxz3nEbHqvz+7EadRWAQ3sOFlLQ== X-YMail-OSG: viPmMR8VM1kZgkDUYr1qT0NsfA.u.fAZ_C0aZNaA0672QXiTz7_CYq7nGzQhW6y oGO4UbkrymUrhMUpDo9Iq4y7jaGe6wLgdRti04rp3v7eYlCQs03kUyehINuyHfvzcjdPQ0fpdUDV LGw5pM8N9pWAFJdoUtnb0pZ1Ft6AgdcW09GeTYyrUNKsgIB7.ptcf141vbK5KlqucE4zeEPKu70z T7VUPodVl6z4YXvCCVXZo6kX.QmH.uHHkmT_OS3JbrR9uqWut2T4OvbCUrP72u0LYoFnjIWSOaJD 2LMbPqXOr.9uWfhNWmmcvg_N16Xg9KPhgGtzdxf7xWDzwWW.uc_dzcxe3fUy3oOHzCLb8sVQ2FBi SLp6gQ3vYdeNli0w5hzi7h2h7o38Z.5zxMBmfUlMllWDnO7.VJ1pIYf6mFBfMLz689e_d2gGbUvm S6.35CWr96aaspSt3KGNCYeWUHvujg183qRSqYVU4EfDfQE19FsCChIfU710Mxpbrz5JObJD2I29 bScA2.uBl7XQwiY5ROg7n3.6f.p4TTmJ9LQNFdLXlAYEpW4XfCnjh11arzwjj7YqdKm4UOF46R7V oWyw560J2VMc65iQxLxqXLyh4NT2kHOrED1QxqUz1tAdhT37on_RCbeaUkigYFFtSSK0vRDGkbsW 60_u_JPzBq4WxnbZvdiSEl3W45d1ENJkcCiG37NHiCa3Zy7LHGqsO.RkPk.CSKYSTy.NJQfRXRbE BywdMb8_hluI3DYh4JcOJkGInwcgSc03M6ICRZsCiJmk_mh6bRNJFEThbUiJ7UxtJPGbd5SvB3F4 0JfU7Ru99ciqBYBgL2bzpW9jNqLPOzG.x3T6xd5A27ZODVM0r4sG9iOcwtRrCVhYHdprd.xE4yut SYLoq0X8rIDJZENFtay_xpcG.KkMLtqLr25sBf8JE5JcLAzI.eF7btjyiq76rZUUoepzmTgG0JvX IeZ7U9WqXk7._8LC.p5cNZFzmg2aqr3uU.So6 cc: zsh-workers@zsh.org In-reply-to: From: Oliver Kiddle References: <20180707205750.GA62923@CptOrmolo.darkstar> <20180708064008.rkjzh2h376kqehs6@tarpaulin.shahaf.local2> <2431.1531053655@thecus> To: Eric Cook Subject: Re: clang completion MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3924.1531085647.1@thecus> Date: Sun, 08 Jul 2018 23:34:07 +0200 Message-ID: <3925.1531085647@thecus> 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