From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 193 invoked by alias); 24 Feb 2018 19:49:24 -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: List-Unsubscribe: X-Seq: 23168 Received: (qmail 11917 invoked by uid 1010); 24 Feb 2018 19:49:24 -0000 X-Qmail-Scanner-Diagnostics: from mail-qt0-f175.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.216.175):SA:0(-1.9/5.0):. Processed in 6.040764 secs); 24 Feb 2018 19:49:24 -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=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_PASS, T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.1 X-Envelope-From: mikachu@gmail.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0Xx7zia9CS54+STG7w9eZpFNH9kYpLtQX2fDwCYvbLo=; b=MPSciyfGrTbkrRxurujNEnaoCC6isA+DVweAFwY8OAQw3aAujmpxocL+O5PdVX2fw/ TYVeCmqoFZNs+qqyJT/Brk0ki6Oj3rKtOzbcLnHkg3KBVovmgybiJtNU4kn4ToBNRcQz VJ9tder/FGeBL83l0loeabmA7eQtW8unLhVNUuowsOTCEHOUzL5/GQ5bM1l2nLoRPGBG 2+67kDIChzWzH6uWNYxWKMKkYImWpUXyQ72015pgY2QY8WEUqs5P900tOzjkr39RoL77 Mqbj3tBB6NVfyHCIz6W+DbI4kRzTge4etrVBj9Do5cJMpR4EilwpUt4O0UxnQGoOxU9A 08Ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0Xx7zia9CS54+STG7w9eZpFNH9kYpLtQX2fDwCYvbLo=; b=FQw96ChGL8vdGm0HzUbyi+g4VozXwSLQ83lqeJeYADPeZs9GnNOvvQxRVKNbOHytH9 0mD1kJuF+f1FTdN0kcFUDhwjSY6cHxl8LqY22a0uNO+Be+6MvKZqaoZsKhcHZxVeY59L utGigzgebUZ3VLPvY87hruuBENmJDgj+4h4V2xf2HrGHKvtUcUvjlZQ5lcxwofxTqDkX Nfsmfy3QTh8qU+IX4RIJtJZVdFv42WsUCRmh7F4wxbPzxP3vy6F/P5p8hMiWlSJzyWUh 8FPyJCblqP4w/LAsm54adI2cSto8/2ZWyZ5/ksDVnj8ziPym7DHCcLdgAJIx+KFauVuL U6Rw== X-Gm-Message-State: APf1xPCzKxf9n15hNZER5+p7xXh3bQBQRHyG3zD1Q4jp4ZDvF3rN/l2/ leqR5pdZdcqePV7PrQbznCaY4uQK4zo9zC8lfK8= X-Google-Smtp-Source: AG47ELt9bXXDtkdz33+r38lRchAA0Ro3nHaJHTVPWoSln4/YVCQKPg50dI0OR6n76X4FXgAHaHoGXiBhcx7wBGRd9bk= X-Received: by 10.237.53.98 with SMTP id b31mr9989473qte.230.1519501754516; Sat, 24 Feb 2018 11:49:14 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20180224193420.0d7d7d5c@ntlworld.com> References: <20180224193420.0d7d7d5c@ntlworld.com> From: Mikael Magnusson Date: Sat, 24 Feb 2018 20:49:14 +0100 Message-ID: Subject: Re: Dynamic named directories and completion To: Peter Stephenson Cc: Zsh Users Content-Type: text/plain; charset="UTF-8" On Sat, Feb 24, 2018 at 8:34 PM, Peter Stephenson wrote: > On Fri, 23 Feb 2018 09:42:37 -0500 > Scott Frazer wrote: >> >> cd ~[ccc]/ >> >> >> >> zsh doesn't give me options for directories under ccc, it thinks '/' is >> >> the command I'm trying to complete. Is there a way to make this work? >> > >> > I don't see anything wrong in your code and for me, it works as you >> > expect (zsh 5.4.2). Does "echo ~[ccc]" returns the right value? >> > >> >> Yes, "echo ~[ccc]" works correctly. I'm using zsh 5.3 so maybe there is some >> difference there. Perhaps there is some difference in options/modules/etc. If >> I cut my .zshrc down to a minimum: > > There's something screwy here, certainly. I don't think it should be > necessary to modify _path_files in 5.3, though, there are certainly > cases where you get the right answer, and I think the logic that currently > handles ~ at the start should do the right thing here. > > I've a theory it's down to the completion widget in use, i.e. how > completion gets started up. If instead of hitting tab, you type x > complete-word --- or instead bind that widget, > > bindkey '^i' complete-word > > and then use tab --- does it start working? The default is > expand-or-complete, and I believe the expand bit is nixing the > completion in this case. (Except we don't really have the word "nix" > this side of the Atlantic, so I may be talking nonsense, but it sounded > good.) I have some patches I was working on related to this, but I assume there was still some problem, or I would have committed them... There's two patches in this thread, http://www.zsh.org/mla/workers/2015/msg01439.html and then I think I never sent the third one, diff --git a/Completion/Unix/Type/_files b/Completion/Unix/Type/_files index 2b0c5580a5..067f68d9d9 100644 --- a/Completion/Unix/Type/_files +++ b/Completion/Unix/Type/_files @@ -103,7 +103,7 @@ for def in "$pats[@]"; do if [[ -n "$end" ]]; then if _path_files -g "$pat" "$opts[@]" "$expl[@]"; then ret=0 - elif [[ $PREFIX$SUFFIX != */* ]] && zstyle -a ":completion:${curcontext}:$tag" recursive-files rfiles; then + elif [[ ${${:-$PREFIX$SUFFIX}#\~\[[^]]#]} != */* ]] && zstyle -a ":completion:${curcontext}:$tag" recursive-files rfiles; then local subtree for rfile in $rfiles; do if [[ $PWD/ = ${~rfile} ]]; then -- Mikael Magnusson