From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2309 invoked by alias); 21 Sep 2016 00:56:29 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 21953 Received: (qmail 14245 invoked from network); 21 Sep 2016 00:56:29 -0000 X-Qmail-Scanner-Diagnostics: from mail-pf0-f193.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.192.193):SA:0(0.0/5.0):. Processed in 0.789534 secs); 21 Sep 2016 00:56:29 -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=0.0 required=5.0 tests=T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: schaefer@brasslantern.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at brasslantern.com does not designate permitted sender hosts) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:to:subject:mime-version; bh=QjcYyaV9QBjRronKUZ+ybVm5iHlPYq7xhfVirIJQHSc=; b=U7+kscAULbNdwlslIBAv2NGYz90bp4KTYOGUAhxJ0GwM18mgqml5h32+wsIRPlGZ3t ntyHXBNRmw7/AiuyhAHgewEVqqmIXxPh3lTwLBa78ltphj+Uwt+XGVwjsNEQfoyglbiK LCtSq4nh+VOQBh8Kf8cGPW8sNcnz3FBYslr4uHAv6KLeByrurrekQXJhBpj9xmXcW/Qe pLH3V4CzvsDS1+THFhYaltPRPFrMGW/7Z6D1qFvYPATO8++e6eTj/n/JnxbSOXGVc30q tvwMt4RtGwGNW3l5lbHLhARF3mKKetOEaLsSfD6V9uJBaOu1jRwMl+KRl9f8Cv5Kac9R 33fA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:to:subject:mime-version; bh=QjcYyaV9QBjRronKUZ+ybVm5iHlPYq7xhfVirIJQHSc=; b=bmX3EbVdlXiasvgVEhcYr7ixxscfVxbqFJ0e5gGKt2fUx7wnukqEVd1SAa+kUos2Xj 3QBYdd4+MMVEgCNMBmIEfPUx8V22O0SUnlO7WYecmY/Xnhr8TG5QufXFCQ2Vee6VR4qv Cgy8ZWsOoRcZy+nNvbl/D6dLbooHVyeBPfrEy03VXD1CBadcnakJonPU6bv768TVLTIq m3sotyk4CbhwKrGC/Nnw3fIMTBkJb6uYS4gOKkaqiXKamYbYAdeQClBI2UyVIBbGQWlb aKAzM+5rGHu+DqjYX+hcYufuYbhPz6Jr5HADb5kjKY1aR4iUlYL2W93R7mV3G7Mh9Fni kSBw== X-Gm-Message-State: AE9vXwMgrFoZiMk4CxIeNQEz8vxd7QdfbGjGI1w99jiStWFeFRhmFe2xW2C84P8tEAPJGQ== X-Received: by 10.98.222.3 with SMTP id h3mr59467425pfg.146.1474419382650; Tue, 20 Sep 2016 17:56:22 -0700 (PDT) From: Bart Schaefer Message-Id: <160920175623.ZM32730@torch.brasslantern.com> Date: Tue, 20 Sep 2016 17:56:23 -0700 X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-users@zsh.org Subject: File completion with **/ (with solution) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii This started out as an email to ponder/grumble about why _match can't resolve a recursive glob. Along the way I discovered a way to accomplish what I wanted ... but I'll leave the leading expository stuff for context, having taken the time to write it. Using the _match completer, I can do (in the zsh source tree) % ls C*/*/*/_main to get the expected result of % ls Completion/Base/Core/_main_complete On the other hand, if I do % ls C*/**/_main I get no result. If I have the _expand completer and manually append a "*" before hitting TAB, I also get the desired result. Or if I have _complete and do ls C///_main then _path_files does magic for me, but I have to use the exact correct number of slashes, which is precisely what I want to avoid doing. The "problem" with _match is that it doesn't change the way that possible completions are generated; it only changes the way the word on the line is compared to the possible completions to select the candidate matches. It was at this point that I re-read the doc for the _user_expand completer for the first time in years. _user_expand looks up the array-valued style "user-expand" and steps through the array until one of the elements yields at least one possible completion, by assigning it to the $reply array. You can read the doc to find out what the elements look like. There are several things about _user_expand that could be improved with features of more recent zsh, and the doc doesn't cover all the other styles it recognized / tags it uses, so that needs update too. However, it's perfect for solving the problem I just described: _glob_expand() { reply=( $~1* ) } zstyle :completion::user-expand:: user-expand _glob_expand zstyle :completion::user-expand:: tag-order expansions all-expansions zstyle ':completion:*' completer _expand _complete _match _user_expand The other thing it might be useful to call out in the doc is to note that because _user_expand is called AS a completer, it has access to more of the zstyle $context when it is called than when the "completer" style is looked up. This could be handy when deciding what to assign to $reply. It would mostly work to include other completers / completion functions as elements of the user-expand array, but note that they'll ALL be tried (rather than only tried until at least one finds a match), because the functions normally won't assign to $reply and that is currently the only way to stop walking the elements. Daniel, this might be the "better answer" to your _match question, too.