From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: zsh-workers-return-43602-ml=inbox.vuxu.org@zsh.org 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 92a81f2c for ; Thu, 4 Oct 2018 18:44:36 +0000 (UTC) Received: (qmail 19888 invoked by alias); 4 Oct 2018 18:44:22 -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: 43602 Received: (qmail 2056 invoked by uid 1010); 4 Oct 2018 18:44:22 -0000 X-Qmail-Scanner-Diagnostics: from mail-io1-f43.google.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(209.85.166.43):SA:0(-1.9/5.0):. Processed in 3.82169 secs); 04 Oct 2018 18:44:22 -0000 X-Envelope-From: dana@dana.is X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | 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=jlHTPZwP9ZegtDve0vHj3Ps1xPch2e5yNcI46KRBmrU=; b=nxIoCwUclMef7eDd5Rss+/JGJZuBZCo5PVTxRKjJPKShi2rTCeGooban3tmNpEOCZg jLmg8fnctmaa0I/JAjh0ZsLaWljO4lQIjib93EhqJwU70MzzmyIs46mPU0Ksm1iJ8bGP GFX7qP/tHisY2hxN+z+35gC64gI+36dRKIjg0E/+bmkVtGPDkYT1Y5Pgnu+RxZnU/pAw 2+LOxh5cCcpy1c9CI1J8AwE8ECmIzvUPYNDQhvxkIy3Xh2j1YGGyWPjIzvDiXQzyupbu H7/tsfQVVs9CPttVK7v72xr7Af2BCIrB9bAOCoDsAFVX0vhWBNiFwbU76eJJ1JVeum1E 39oQ== 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=jlHTPZwP9ZegtDve0vHj3Ps1xPch2e5yNcI46KRBmrU=; b=sITkNUrh4WKzfUgZxzdWF3t6n+sWT71Mtuc7tTOC5+HTET7190wnceCw3k0FtNQmI+ iWpK52iNUzgxuX9y97HCY1X0Z8CeIkTFLAA2DuC3tbd9ngMVOoNWxLqtK4aDzt51KOsZ rYMQiHequUYNSuKq8+kmJXregwSYm7FW1/HHoLk7yqSg/SAGwpACmMrPsd/nO6NScti4 8EqzPKP0ub2q6FIlbPxh8buvMCTEodGPmaa5uvoxOoEwCWrgNcEqXR3ctWQFZOG4Xw11 oZSMMr0LpMFGpEo/Q/ePyBlsBdjkZm+VjKuwDFbW6y1HQJjYsuz8V/CGDyDBMPRfZwfQ qfjg== X-Gm-Message-State: ABuFfojrLgFpH06B9EFdmsg9mg0T+azp6OgqmnTn3Re8u4aRicevjxQh aeiGz+8O26fH9K6I2EwTksZl6w== X-Google-Smtp-Source: ACcGV63We7GyeM7S+s4XscSJGUZ6vDlMIvZ/BLwQzz9hcvistfdLzLpzaan7jmnTnYaHnEvwRlYDBg== X-Received: by 2002:a6b:4610:: with SMTP id t16-v6mr5308416ioa.284.1538678655223; Thu, 04 Oct 2018 11:44:15 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: [BUG?] Unexpected behaviour with `compdef -p` From: dana In-Reply-To: <20181003170233eucas1p1e6f2fdb6bf9aed8e0b2da1848c8405df~aJ-SE1R4G0648706487eucas1p1n@eucas1p1.samsung.com> Date: Thu, 4 Oct 2018 13:44:13 -0500 Cc: zsh-workers@zsh.org Content-Transfer-Encoding: quoted-printable Message-Id: <78371772-073C-4449-BA93-CDEE84B4D5D4@dana.is> References: <97754736-115B-4EF2-B10C-9DE17345C9DB@dana.is> <20181003170233eucas1p1e6f2fdb6bf9aed8e0b2da1848c8405df~aJ-SE1R4G0648706487eucas1p1n@eucas1p1.samsung.com> To: Peter Stephenson X-Mailer: Apple Mail (2.3445.9.1) On 3 Oct 2018, at 12:02, Peter Stephenson = wrote: >The code's not *that* complicated, this time Yeah, i guess it's not so bad. Looking at it more, and also looking at how the very few existing = functions that make use of `compdef -p` actually do it, it seems like maybe it's just = the way it's supposed to work? The thing that determines whether it moves on to normal completion is $_compskip, which can be set to 'all' to make it stop after it finds a = matching pattern. This is what _init_d and _zftp do, and both of those just so = happen to have been written by the same person that added pattern-based completion = (Sven). The manual does kind of hint at this, but it's not very clear. To make = matters worse, the documentation for compdef is spread across one section for = the #compdef tag and then another section for the actual compdef function. I = feel like it should be consolidated as much as possible to one or the other, = but it'd be a pretty big change that i'm a little nervous about making = unilaterally. In the mean time, here's some clarification. dana diff --git a/Doc/Zsh/compsys.yo b/Doc/Zsh/compsys.yo index 65f596752..a5a9e5b5d 100644 --- a/Doc/Zsh/compsys.yo +++ b/Doc/Zsh/compsys.yo @@ -489,7 +489,11 @@ The parameter tt($_compskip) may be set by any = function defined for a pattern context. If it is set to a value containing the substring `tt(patterns)' none of the pattern-functions will be called; if it is set to a value containing the substring `tt(all)', no other function -will be called. +will be called. Setting tt($_compskip) in this manner is of particular +utility when using the tt(-p) option, as otherwise the dispatcher will +move on to additional functions (likely the default one) after calling +the pattern-context one, which can mangle the display of completion +possibilities if not handled properly. =20 The form with tt(-k) defines a widget with the same name as the = var(function) that will be called for each of the var(key-sequence)s; this is like = the