From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from primenet.com.au (ns1.primenet.com.au [203.24.36.2]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 0b6845a5 for ; Mon, 26 Nov 2018 03:10:11 +0000 (UTC) Received: (qmail 14421 invoked by alias); 26 Nov 2018 03:09:58 -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: 43843 Received: (qmail 13755 invoked by uid 1010); 26 Nov 2018 03:09:58 -0000 X-Qmail-Scanner-Diagnostics: from out4-smtp.messagingengine.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.100.2/25112. spamassassin: 3.4.2. Clear:RC:0(66.111.4.28):SA:0(-2.6/5.0):. Processed in 6.135365 secs); 26 Nov 2018 03:09:58 -0000 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=message-id:from:to:mime-version :content-transfer-encoding:content-type:date:references:subject :in-reply-to; s=fm1; bh=YZXFfEtJasmu3QZrYjjQ/Md/ig0NnW0F1fK0zh1b 1RM=; b=nGmjS04kDjZOBp9Q2lP+oqwGicOuUj66Y8A51NuGhunwen/+HfP9r3Lu FJ90ZLHHceGHXj2ErCzdpI8dfAtqE0HL1TUbNQuSVn5lmFLTKGRTcyljLlwBjZd0 AcFnPF6KcelPbJ5RUH2Ka5otN5eJL6ydRX3HyybyqG00u8RQUvRfZM0BGxHQEztq ciCZADxCpJKpPrYzuueYvpEgySnuLvKSeLRYK+Llp5ULUJarN2GwUUaKFXGdMb3l kqng1iMUoTmgl1BsYjAeD7C68leUJtlpGH7hj2CxHCSaYwfLIt8RdOFDE0CjPouV zCWWAYgcfYLVSIR5rXYQ1g6cWtRK4g== 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=YZXFfEtJasmu3QZrYjjQ/Md/ig0NnW0F1fK0zh1b1 RM=; b=ILFEGJbAOkrNvpJYIC56VSu7hOUthW9WDjmfD2fwKcwUg5cKx2yZhNBbF 6OgiQ8VpA0TH9XUTxbMOvCI/1N1OcmyQ1I+QqqWKdT4YUe6MWmug4akBmccEIXhJ UiofThTmASyjcRZTwkKEjFMmN/0ooFy2qB6Bh3CBX2UxCTuUxlfVWOM3Zh1msYDf rsj43PDsHJT+CLNJHTu6g7yL+LLjnd4MKAlc6Xj3j3BbGLKlLyFsyfJm3hwTbPgN eO2wjQTQnY7g8mjRRc1JHTxGk+ZsgotP9FMcgO80m80GD+5EuQ30mGvAR0IjDr0i TgeNxV4ipBq0kyEtypL3K1QrOMV9A== X-ME-Sender: X-ME-Proxy: Message-Id: <1543201779.3048772.1588561784.55C4BFED@webmail.messagingengine.com> From: Daniel Shahaf To: Zsh workers MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-3449945b Date: Mon, 26 Nov 2018 03:09:39 +0000 References: <75B26F45-E6E6-44BB-80A4-7301CBE480FE@dana.is> <88812-1541586959.338018@YaNA.ZOZt.NKaA> <76839-1543195550.251964@c6AU.RX4q.p78d> Subject: Re: completion match ordering In-Reply-To: <76839-1543195550.251964@c6AU.RX4q.p78d> Oliver Kiddle wrote on Mon, 26 Nov 2018 02:25 +0100: > On 7 Nov, I wrote: > > You can do: > > _arguments '-b-:level: compadd "${(@)expl/#-J/-2V}" ${(on)levels}' > > But what you have is perhaps better, especially as it's duplicated for > > -b and -e. >=20 > The patch below is an initial experiment for what I was suggesting. > It allows, e.g: > _arguments '-b-:level:compadd -o numeric -a levels' >=20 > Any thoughts on the interface? Is something more terse like -on > preferable? The -V option becomes superfluous (but remains for > compatibility). Instead of -V grp you can use -J grp -o nosort. > Do we need to worry about this breaking uses of the old -o? In general, I would default to assuming we should worry about compatibility, unless there's a specific reason not to. (As a user, I assume that my zsh code is forward compatible with new zsh releases unless something is specifically documented to be an exception.) Is there a reason for this case to be an exception? If people use =C2=ABcompadd -od foo -a bar=C2=BB in 5.6.2, what would the failure mode be? > With this the existing, -o would become -o match and becomes a property > of the group rather than the match. Being associated with the group is > more consistent with related options like -1, -2 and -V. It might be > confusing that it doesn't work if no group is specified, however. Sounds like bin_compadd() could detect this situation and warn. > Currently, given two -o options, only the first applies, This is > consistent with -X, -J etc even though I think it would have been better > if the last of these were used. In many cases where functions use > zparseopts to extract compadd options, they should be using J+: rather > than J: as zparseopts is taking the last one only with J: No, what they *should* be doing is passing arguments transparently, without parsing and reserializing them, so when we add "-$letter" options to compadd we can do so by changing just one place (namely, the C struct declaring the builtin). Probably by putting the compadd options in an array and passing its name, or by putting them in ${argv} after ${argv[(i)--]}, etc.. Cheers, Daniel