From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17950 invoked by alias); 30 Aug 2016 07:03:07 -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: 39123 Received: (qmail 23495 invoked from network); 30 Aug 2016 07:03:07 -0000 X-Qmail-Scanner-Diagnostics: from mail-pf0-f177.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.177):SA:0(0.0/5.0):. Processed in 0.846203 secs); 30 Aug 2016 07:03:07 -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:in-reply-to:comments:references:to:subject :mime-version; bh=v6FpBLgYTzVtj6REFsBHlEvO3GrTv0Mw17NoscBCRyA=; b=FCt8vH549PJnVZo1cZ/Q6HEGEZ0lqxzqUz0g2Wnk0BbIt15lUkcsxGh4UGDZVvd1EL Dp7hg1URgFmgs8qdESKKB7mWbjy8uzL/RQ+/RZVLOK4QZyXWxq6Ru3dmYP1eF4vjhViP pIIpUULdxfwY7JuQjF5Q2AaMt66Wc6y+Rr/3xTjgTwNOCmVzTBV0l8IVzxHRVPq6g+Cp sVRWTY93S72I51tPZ9R8P5RVnVXM6Ut3qnVogafw3Bwniqxg4dtl3lD80G2ZMbQblroE C9coUvKL0EOgi3uWxvSFt37/2fHNmst/73TKMJuh95NTnIuw3CVIV6uD3QWV2vLDtKnj l5fQ== 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:in-reply-to:comments :references:to:subject:mime-version; bh=v6FpBLgYTzVtj6REFsBHlEvO3GrTv0Mw17NoscBCRyA=; b=KyEpkaSVIWxLZJCT0BBciPVwweeOPsvQGhWF6gwZFbi+9bw+CcXeDmBQrrKnB25ZBi Vt+AH61Wz8Akk3gd0IdyQ9DGtaSUppbU9cTHV5D5ncVNWRLp/mGMVnqisqMSSuS8vn0n Z2dj3Aj0UWJXfY4WL3sOgnSGw9kmHjRDNFhWlcU+aA3UvNuqgaXhL82SDyMF93fOdJvN fMNMpDjAndCGdHJwVyob3o4d4n4hy1xj0gk2fQRUaZ+mgfXHKf+H1zkq/5o1cNyWbSfV bp+vYbIlNzE987OY9we5XBuWVf04sEVZKCVrjKpAfn+mS4oKRk8C4dk/ecqMO97PHC3L 3tfA== X-Gm-Message-State: AE9vXwNg/IegGwPyjVQHZ57cFKDY2OApj/SkrNQVGDjPKljw9iLc4Byo0PEkE2WlKRrF9g== X-Received: by 10.98.74.91 with SMTP id x88mr3527222pfa.79.1472540579754; Tue, 30 Aug 2016 00:02:59 -0700 (PDT) From: Bart Schaefer Message-Id: <160830000331.ZM9651@torch.brasslantern.com> Date: Tue, 30 Aug 2016 00:03:31 -0700 In-Reply-To: <20160824191313.GA31943@fujitsu.shahaf.local2> Comments: In reply to Daniel Shahaf "Re: file completion(?) erases word typed" (Aug 24, 7:13pm) References: <20160823224842.GA24864@fujitsu.shahaf.local2> <160823225204.ZM19950@torch.brasslantern.com> <20160824191313.GA31943@fujitsu.shahaf.local2> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: file completion(?) erases word typed MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Aug 24, 7:13pm, Daniel Shahaf wrote: } } I don't know why list-choices would act differently to expand-or-complete. Some additional clues ... Using my example (because I don't have gtk-* installed): torch% f /usr/local/bin/zsh-5 Here the word on the line is not yet the longest common prefix of any of the possible matches. So we enter compresult.c:do_ambiguous() and on line 786 we delete the entire word on the line, but ainfo->line has a prefix, which is inserted by cline_str() at line 789. This happens to be the same word that's already on the line. Because a prefix has been inserted, the set of matching suffixes is listed. Next with: torch% f /usr/local/bin/zsh-5. We arrive in do_ambiguous() and hit line 786 as before, but this time the string that was on the line is already the longest common prefix; so now ainfo->line does NOT have a prefix with which to replace it. In this case cline_str() should re-insert the original word from the line, which is present in ainfo->line->orig, but for some reason the value of ainfo->line->olen is zero, so cline_str() ends up doing nothng and the erased word is never restored. ainfo->line->olen appears ultimately to come from add_match_part() called from match_str() at line 739 of compmatch.c; it's merged from there into ainfo by join_clines() called from add_match_data(). At this point, though, I get lost trying to keep track of what's going on with l + loff and llen (which comes from mp->llen) and ll and all of Sven's other usefully named variables. ====== I *think* what it comes down to is that the matcher-list is causing the path prefix to be mapped to nothing so as to be able to complete the basename of the command, but because completion wants to wait for a second tab before starting the menu on ambiguous results, it ends up throwing away the data that it would need to do anything useful when that second tab finally arrives. This hypothesis is supported by the fact that using zstyle to force entry into menu-selection results in completions being available. However, I don't know whether the right thing is to recognized that the prefix is going to end up empty and jump directly into the menu without looking for the second tab, or to second-guess the matcher code and re-insert the original word when that fails to do so; or if there is instead a fix to compmatch.c needed. And I don't presently have any idea how to implement any of those choices.