From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 927 invoked by alias); 24 Aug 2016 19:13:34 -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: X-Seq: 39098 Received: (qmail 4622 invoked from network); 24 Aug 2016 19:13:33 -0000 X-Qmail-Scanner-Diagnostics: from out2-smtp.messagingengine.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(66.111.4.26):SA:0(0.0/5.0):. Processed in 0.677098 secs); 24 Aug 2016 19:13:33 -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: d.s@daniel.shahaf.name X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at daniel.shahaf.name does not designate permitted sender hosts) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= daniel.shahaf.name; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=9QIs/Lr5AhFauYiN jYIqSRqWirA=; b=UEgVw5gkdQqE1hRtB27w7kp6xI71mtVtuYdPDm+F4ClP5p8o Xjf44IRB7oWoNSYOsYq8khM4nisUDIpKlsuP6A78HXyGyHXKVq5GYaJbp+ZK/q/j vDrnLkP8LIvpcqWbHxFgYd0DIWuV7nhDv2LYcGJZSsvoSvZ8miylxycJf5E= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=9QIs/Lr5AhFauYi NjYIqSRqWirA=; b=YFOYbGRTrk06q0glitl7wII/bw23TeMhjubYfBnvt3mUDP9 fEQBhx++fKIww+szs8nuhRlvdnRzGGRfv5SyTVqiIFBbpk7a/AgSP1cRe0CX0zyB PAw9ZJ29V6G+VFUAjfrK74PVkDs3yydJYFIQYdPxdtEwW0c/AWpFayfmdnYM= X-Sasl-enc: 55UUmkuHeBLWHHgn5Gr6EqhSBGY70ZuYUf80g0mUDNME 1472066006 Date: Wed, 24 Aug 2016 19:13:13 +0000 From: Daniel Shahaf To: zsh-workers@zsh.org Subject: Re: file completion(?) erases word typed Message-ID: <20160824191313.GA31943@fujitsu.shahaf.local2> References: <20160823224842.GA24864@fujitsu.shahaf.local2> <160823225204.ZM19950@torch.brasslantern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <160823225204.ZM19950@torch.brasslantern.com> User-Agent: Mutt/1.5.23 (2014-03-12) Bart Schaefer wrote on Tue, Aug 23, 2016 at 22:52:04 -0700: > On Aug 23, 10:48pm, Daniel Shahaf wrote: > } > } I noticed something odd in a completion function that (eventually) calls > } _path_files: > } > } % git config sendemail.smtpserver <^C> # autoload > } % compdef __git_sendmail_smtpserver_values f > } % f /usr/bin/gtk-update-icon-cache-3. > } % f > } > } It erased the word I'd typed. > > I'm not certain what's going on here either, but loading up a few more > zstyles and using a completion that's not unique might have provided a > hint: > > torch% f zsh- > torch% f /usr/local/bin/zsh-5 > Completing hashed command by absolute path > /usr/local/bin/zsh-5.0.2-dev-0 /usr/local/bin/zsh-5.0.8 > /usr/local/bin/zsh-5.0.3 /usr/local/bin/zsh-5.1 > /usr/local/bin/zsh-5.0.4 /usr/local/bin/zsh-5.1.1 > /usr/local/bin/zsh-5.0.5 /usr/local/bin/zsh-5.2 > /usr/local/bin/zsh-5.0.7 > Completing file > zsh-5.0.2-dev-0* zsh-5.0.5* zsh-5.1* > zsh-5.0.3* zsh-5.0.7* zsh-5.1.1* > zsh-5.0.4* zsh-5.0.8* zsh-5.2* > > Note that it lists the individual files as possible completions. For > one of those to match the command line, the /usr/local/bin/ prefix > would have to be erased. > > Repeated whacking of TAB at this point menu-cycles through only the > "hashed command by absolute path" selections, the base file names are > never offered. With the following style set, basenames are offered: zstyle ':completion:*' menu 'select=long-list' 'select=3' > If I append the "." and use list-choices (^D) I get the same listing > as above, but as soon as I hit TAB instead, the whole word is erased > like your example. It seems "." isn't special here at all: in my original reproducer, «/usr/bin/gtk-update-icon-cache-» erases the word too. (Without the last hyphen it'd still be ambiguous) I don't know why list-choices would act differently to expand-or-complete. > There are a couple of curious tidbits in the _complete_debug traces. > > Here we add the command path but tell completion that the path prefix > should be removed from the resulting command line when completing: > > +_hashed_absolute_command_paths:6> compadd -M 'l:|=/usr/local/bin/' -J -default- -a 'commands[(R)${~i}[^/]#]' > > Here we add all the base names but say the path prefix should be pasted > back on -- but (weirdly) that the path without its leading slash should > be an ignored prefix: > > +_path_files:713> compadd -Qf -J -default- -p usr/local/bin/ -s '' -W /usr/local/bin/ -M 'r:|/=* r:|=*' -a tmp1 > > I have no idea why ignoring the path minus its leading slash would ever > be correct, but in any case this appears to be adding the full path by > two different and contradictory approaches. What _absolute_command_paths intended to be is: - You can type a command name and complete it to its absolute path, e.g., ls → /bin/ls; - You can type in an absolute path to an executable file, even if that file is not in $PATH or in $commands. So, when you complete something like /usr/local/bin/foo → presumably /usr/local/bin is in your $PATH — both alternatives add /usr/local/bin/foo* matches; the first alternative lets you type 'foo' to get /usr/local/bin/foo* matches and the second alternative lets you type '/usr/local/bin/foo' to get those matches. The first alternative shouldn't be adding any matches in the situation of the minimal reproducer. Cheers, Daniel