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.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, 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 4d02c75a for ; Sat, 2 Nov 2019 06:45:46 +0000 (UTC) Received: (qmail 14665 invoked by alias); 2 Nov 2019 06:45:41 -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: 44885 Received: (qmail 17648 invoked by uid 1010); 2 Nov 2019 06:45:41 -0000 X-Qmail-Scanner-Diagnostics: from mail-yw1-f46.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.0/25615. spamassassin: 3.4.2. Clear:RC:0(209.85.161.46):SA:0(-1.9/5.0):. Processed in 2.849467 secs); 02 Nov 2019 06:45:41 -0000 X-Envelope-From: dana@dana.is X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.161.46 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dana-is.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1fsVuOtP1ToiTQiWrV7acj5lNCtOJ6dmu4UCA0GeoIE=; b=WndfQBu6O8vLo+1fwuZadaXq+xI1WQQc5KzOHrSpwgunM0S8hsc6v86HMTLgEZPfWW gWpqz9ufqeZ5unQs9I9KOnssD5B0l+UaG4MhJ/zuPqZEYwy60R+fr5fH0O+ZYtpqcmA4 Az7jsZTtEu09qc8bdcHsMdn9fr39lvTNW+G9garOt897uiuWXPcA6xMdrOAWyG+dawOJ CjDZt0KPzu3xBZ+hriEBxr51ERkX5I6Sx3UlAZnbF50ZoLIB6pKYP/WVj8mRQZzO7VHk CRLd9+/ShxgR5gsRQIUYqPN5Y+ZcvnHxtBt9bmsaSXJdIqnyVtiau+eYKwBB9bTi8G7u MIDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1fsVuOtP1ToiTQiWrV7acj5lNCtOJ6dmu4UCA0GeoIE=; b=ZGHqidzrB9ZvqHd7frA45hY0n4GoUUR0JYeRrlmpN38z0Q7coKJV/eVzZwRVb/2Y0C 6Ia3zav/gmtdl4sCky+O5uSFTXE6DU8EH+QrUupl618T8RZqU4r+wpPqcIwHT6DGps7V kkWW16pKrRRUlZ1kOEMVLGnT8tpKGVnXKrmBiOIwQVliIBhNX3SINKERhGqZ6+2jz2tD QU4eAw6xO+rchwz4kIilYWsZHYGPMQcmqLt0RkhLEswE33jlT9UDW6FyQ0O97cVGk0Xm nr9qkgu28Fd95w8PaQFhb43DOiiWjsW2nHNiqmFIFjWb0+tPtZyFjuA7K4TCTfSQ2u1N hg9A== X-Gm-Message-State: APjAAAWVNo6iR8gx9szZd1gevbIYYeSLatHV+gme/XQhiKpdJOKR1fF7 vGHLcjmZktmVcc3bfexb2mcoNJIl9vzwDg== X-Google-Smtp-Source: APXvYqytsLFV6eId7xOWXrgMsqrxOJuBDhoqkOvtSIGdiHZonylgFd+uHE+AEvJeEKHFUfw9/p+v4A== X-Received: by 2002:a81:bf52:: with SMTP id s18mr11671497ywk.192.1572677105003; Fri, 01 Nov 2019 23:45:05 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: [PATCH] Completion: Add _log_priorities, _logger From: dana In-Reply-To: <20191102055423.5gzbipni3vnjo4k3@tarpaulin.shahaf.local2> Date: Sat, 2 Nov 2019 01:45:03 -0500 Cc: Zsh hackers list Content-Transfer-Encoding: quoted-printable Message-Id: <4D918504-B8F4-46D5-9F04-8B223A56FDEE@dana.is> References: <20191102055423.5gzbipni3vnjo4k3@tarpaulin.shahaf.local2> To: Daniel Shahaf X-Mailer: Apple Mail (2.3445.104.11) On 2 Nov 2019, at 00:54, Daniel Shahaf wrote: > That is: use up _one_ top-level option letter and stuff all the = not-compadd > --options and their arguments into the argument(s) of that top-level = option > letter. That would definitely work, and be easy to parse, though it is a bit unattractive, especially given how these functions are often called. = e.g., you could end up with _arguments specs like: '--foo=3D[specify foo]: :_my_type -Y "-a \"my optarg\" -bcd"' Granted, very few type functions have options that take arguments, so it probably wouldn't come up that often, but... On 2 Nov 2019, at 00:54, Daniel Shahaf wrote: > We can also do: > . > _log_priorities "${compadd_options[@]}" -- = "${compadd_positional_arguments[@]}" -- "${log_priorities_argv[@]}" > . > which is similar to what zargs does. Normally there would be a = question here > of how to escape a literal "--" in $compadd_positional_arguments, but = for > compadd specifically, I think the following is a satisfactory = workaround: Aside from the literal -- operand thing, there are a few complicating = factors i can think of with that: 1. Lower-level functions like _arguments want to automatically stick = compadd options at the beginning of those functions' argument lists, so = either they would have to be changed to pass the two --s (potentially causing = issues for existing type functions that don't expect them) or you would have = to include the --s in every argument spec you wrote. 2. Related to what you mentioned: Because compadd options go at the = beginning, whatever is parsing the function's arguments needs to know all about = what options compadd takes; otherwise it could get confused by an optarg = of --. 3. Your type function has to figure out how to parse all of this, which = could lead to a lot of noisy and possibly error-prone boiler-plate. I think #2 and #3 could be solved by a helper function that does like a two-pass zparseopts, but i'm not sure about #1, or about the path = forward for existing functions in general. (Though, one benefit of your first = suggestion, if we made sure to pick a letter that no type functions currently want = for themselves, is that it would be pretty straight-forward to just update = them as we go, and then maybe some years in the future we could deprecate/remove = the old way of doing it...?) On 2 Nov 2019, at 00:54, Daniel Shahaf wrote: > I'll leave it to you to decide whether it's worthwhile to change > _log_priorities from the version you posted. I'm definitely open to it, just want to make sure it's something = everybody agrees with that'll work going forward. On 2 Nov 2019, at 00:54, Daniel Shahaf wrote: > Which reminds me: Shouldn't we mention _log_priorities in the manual, = it > being a new Type/ function? I'm not actually sure. zshcompsys mentions a few type functions, but = they're only the really general ones like _files. Aside from some passing = mentions, there's nothing in the manual for stuff like _hosts and _pids and = _signals. I always assumed that was a deliberate omission, so i've never bothered = with any of the new type functions i've added. dana