From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25034 invoked by alias); 17 Nov 2016 23:16:18 -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: 39968 Received: (qmail 28553 invoked from network); 17 Nov 2016 23:16:18 -0000 X-Qmail-Scanner-Diagnostics: from mail-vk0-f49.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.213.49):SA:0(-0.0/5.0):. Processed in 0.830131 secs); 17 Nov 2016 23:16:18 -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=RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_PASS,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: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.213.49 as permitted sender) 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=UUJw+aVHkn9AtOkwd1ttEwxo59wS72Ih0sXK4xSnRnE=; b=vbFf9qaeukFv9xF5tuTVXS+aanLZd14jYpc+AALRfFVp515rPCGXGJjYxw6K8k2fOp 0VDMUzLVmpcKmmti6X/aFqksfoIcehnI68ubz4ennpZ9QamRPM+NSrLNQVEDmKpa+TSL DLma9OLlnzqKWqvwA/ExXmcwqlicVRBZ9/w3vJjfwOPkv0uFpZkHIUaH6GGP24rvM05k nXYHOK7AFg/eL5ngqV9WX7bqX25e6vR6PuH9u7iocVXYlerjdPxuM6SC+pV6mzFq5rRD JtmZ9+jzuhYT62bsTQSikY6kRKTc6ev+vIUwUpRyudkyHzotC8bSQS/GVXl6GuIch4QV /IGA== 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=UUJw+aVHkn9AtOkwd1ttEwxo59wS72Ih0sXK4xSnRnE=; b=jJ4aL5hbvf/HxwDNkyqqg8a+gv3Wf4ptA+2Gh31k5fSJ/YRAco48bJgxMdoBoRRD7O GS6vhL1PuxyTsJ8qFixKmnv5KRRaw15wXVD3La0fmjCkd7ZyOVgCgZ1kcxzoj/RtIXeu OfKRFx0QNGA3It62KmvC0KxJSsvJaFFYd0Pk1kNi+4EdyzZdYRagTe1UQdDIDbHvD1yw JgUck7EoPBOhWHNyauM5AL9c7hT4xvD+FnCkH25/8IEu2o3SizFRJZhStkoj75WfRJyl vrq1L18H6bkSSdMnSiYRLg0KaWwIXzbF59fzTkKOPW27S6il1tm/9z+mPqa3gxTX17bd Rb4A== X-Gm-Message-State: AKaTC00zKvLY0UwNc8PmX4uf2IMkgiztuJRFWKsFsiDJ9LWFYZAID4iueBQTwOqdnDxvkA== X-Received: by 10.31.92.215 with SMTP id q206mr2770655vkb.104.1479419464180; Thu, 17 Nov 2016 13:51:04 -0800 (PST) From: Bart Schaefer Message-Id: <161117135117.ZM11086@torch.brasslantern.com> Date: Thu, 17 Nov 2016 13:51:17 -0800 In-Reply-To: <20160823224842.GA24864@fujitsu.shahaf.local2> Comments: In reply to Daniel Shahaf "file completion(?) erases word typed" (Aug 23, 10:48pm) References: <20160823224842.GA24864@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 I think the comment included in the diff is fairly explanatory. This change means menu completion sometimes starts earlier than expected (i.e., on the first or second tab instead of on the second or third) but that seems preferable to throwing away the set of matches and starting over at what is probably the wrong place. It's likely that there are still situations -- probably including _multi_parts with separators other than "/" -- where this heuristic fails, but this should catch a lot of common cases (I hope). If I'm wrong about any of the assertions in that comment, please point out how the tests could be tweaked. diff --git a/Completion/Base/Core/_main_complete b/Completion/Base/Core/_main_complete index c292ce7..01e6eaa 100644 --- a/Completion/Base/Core/_main_complete +++ b/Completion/Base/Core/_main_complete @@ -284,6 +284,29 @@ if [[ $compstate[old_list] = keep || nm -gt 1 ]]; then fi fi + if [[ "$compstate[insert]" = *unambiguous && + "$compstate[old_list]" != keep && + "$compstate[nmatches]" -gt 1 && + ( "$compstate[insert_positions]" != *:* || + "$compstate[unambiguous_positions]" == 0* ) && + ( "$compstate[unambiguous]" == /## || + "$compstate[unambiguous_cursor]" -lt ${#PREFIX} ) ]]; then + # + # We have multiple matches but no useful common prefix to show. + # This would result in either erasing an existing prefix on the + # line, or adding a prefix that breaks subsequent completions. + # Instead, forcibly enter menu completion to cycle the matches. + # + # The above test is heuristic; what we really need to know + # is whether compadd -U or -M is going to cause the current + # string on the line to be shortened or removed, but that + # information isn't present in the user-visible state. The + # test for unambiguous == /## ideally would apply only for + # file completion, but there's no way to detect that either. + # + compstate[insert]=menu + fi + if [[ "$compstate[insert]" = *menu* ]]; then [[ "$MENUSELECT" = 00 ]] && MENUSELECT=0 if [[ -n "$_menu_style[(r)no-select*]" ]]; then