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=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 06b36a34 for ; Sat, 4 Jan 2020 02:05:20 +0000 (UTC) Received: (qmail 10131 invoked by alias); 4 Jan 2020 01:46:49 -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: 45227 Received: (qmail 9742 invoked by uid 1010); 4 Jan 2020 01:46:49 -0000 X-Qmail-Scanner-Diagnostics: from mail-lj1-f195.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.1/25677. spamassassin: 3.4.2. Clear:RC:0(209.85.208.195):SA:0(-1.9/5.0):. Processed in 3.22603 secs); 04 Jan 2020 01:46:49 -0000 X-Envelope-From: schaefer@brasslantern.com 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.208.195 as permitted sender) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ez/rYTRhIZUUZtWaBGbqR0qi9yRG6xFk5nG8X4ozF+w=; b=pJp2+X5xircMQQrtN4Uf+g7hMEzCgMrERbJd47PSUl/GX5cOuEayW4/ATeprwf7w7K Mot5fbiTSUns8lX/ZKmsiuaRpalWvn1zaeiNqncrAHVc70HnowO2wuwe/g5+os++StLy fmRoUM7IMBEzazoRRQpeh1QlqIyA9Yx7DIRs1Dxb3/uiskbtbKhchUZGJw3zJf8Adq3m 40QZ4t0W/wBdyx1CR9TD6VnovUQ4sfp7irolZGN8g0O8izFA7FvmvpC81jtkVec8lhEY /IcXF2s4fJ1YvWuWq8lhS080W4rGjLNiHIK52XrJ6P9gueISmqFhw7pz7y122QWxee9u e7mA== X-Gm-Message-State: APjAAAWxyW9g5vk3Dwmi5huKlxnOw3dNtz0JgTXGW57VFbxP3JJCGM/5 besGSLUknlxq52MWqoTkbrTPkzoI+VWbBdyW7yFA6rRyoG3Lag== X-Google-Smtp-Source: APXvYqyh2OaivKNqDWy/g2OgDnAcAMKyYhCnNRLyZsU1UwXAScQdgxWnqTJdbsy+pxjclFw6xoIuk49mPdZ00MRmY/k= X-Received: by 2002:a2e:96c6:: with SMTP id d6mr23936842ljj.4.1578102373169; Fri, 03 Jan 2020 17:46:13 -0800 (PST) MIME-Version: 1.0 References: <83C0ABA0-99A5-4DAD-98D6-DBB919F61E24@dana.is> <20200104003913.3gq5hnlmhndwbzz4@tarpaulin.shahaf.local2> <07B00625-9EC2-454E-B3E0-6F520DE4A899@dana.is> In-Reply-To: <07B00625-9EC2-454E-B3E0-6F520DE4A899@dana.is> From: Bart Schaefer Date: Fri, 3 Jan 2020 17:46:01 -0800 Message-ID: Subject: Re: [PATCH] Improve _man file-path completion To: dana Cc: Daniel Shahaf , Zsh hackers list Content-Type: text/plain; charset="UTF-8" On Fri, Jan 3, 2020 at 5:16 PM dana wrote: > > On 3 Jan 2020, at 18:39, Daniel Shahaf wrote: > > Aside: > > > > % compdef _f f > > % _f() _files -/ > > % f Util/ > > . > > offers files, rather than nothing. Bug? > > I seem to recall this being discussed before, and it isn't really a bug, but > we could change it if we decided to. Yes, this was a design decision. As I recall the conversation ended up with something along the lines of "if the user has completed all the way down the directory hierarchy, he probably expects to see something at the end, rather than nothing." I suspect this does make it somewhat more difficult than it should be to create zstyles that display files and directories in separate groups in a completion listing.