From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 22223 invoked from network); 15 Jun 2020 22:25:58 -0000 Received: from ns1.primenet.com.au (HELO primenet.com.au) (203.24.36.2) by inbox.vuxu.org with ESMTPUTF8; 15 Jun 2020 22:25:58 -0000 Received: (qmail 3340 invoked by alias); 15 Jun 2020 22:25:50 -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: List-Unsubscribe: X-Seq: 46047 Received: (qmail 25363 invoked by uid 1010); 15 Jun 2020 22:25:49 -0000 X-Qmail-Scanner-Diagnostics: from mail-oi1-f176.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.3/25842. spamassassin: 3.4.4. Clear:RC:0(209.85.167.176):SA:0(-1.9/5.0):. Processed in 2.674298 secs); 15 Jun 2020 22:25:49 -0000 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.167.176 as permitted sender) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=j7t+V21fnraky/otFOc2xIFKF9SH0x8NdmDMHpkGqiA=; b=Hxr2MEgpylQLa4sO0MBQDqbf2i59i9ov29SGST8Ts1SLdf1h3HKdjS6wD/zi3d+Rl2 ATfodN9DvkL9ij5wbfpY3BaHOx51Y5FRcprxVqwd0sOYBZRUJAe6cvgo6FDeFDKZXAF1 2Y9N7CQIH4xMgLh7G8uWSU7GZAu7JqXQzSA2dS2wn5byDRFkLRh7hvDeok2lvSL/WsVW kALKl5Qrx4qwwfh2zTobEFWasymV7UCM/HjRoYhJ6zcM3FLbkc6cVLt1lt9AdFBgwIOU 8vlxM25GApBYOutqvd+KS9yFfCZG7wXqkHZED0WM3PTfiJRhP0O71aNxWLVSS7agaeL+ XoTw== X-Gm-Message-State: AOAM5328MPqvlTZxerlwYTBqJkIqq4TOcgNHUJrEHBFOnhyo2NihLM3x 1oo+hrpHG4g4U8t2xwJyjAuQapfrpbJHQXxm1VPayz9UyH8= X-Google-Smtp-Source: ABdhPJzCxmjnpJGRlTlL3bNRcVU+9iADyxNa2jBXp39Dp0aHSzMeDz6qDCO7+i/eniI7dOZtPoniQlgmKP7uhcvUDqU= X-Received: by 2002:aca:cf15:: with SMTP id f21mr1212077oig.173.1592259912823; Mon, 15 Jun 2020 15:25:12 -0700 (PDT) MIME-Version: 1.0 From: Bart Schaefer Date: Mon, 15 Jun 2020 15:25:01 -0700 Message-ID: Subject: Blast from the past: workers/18841 To: Zsh hackers list Content-Type: multipart/mixed; boundary="0000000000007eaad605a826e650" --0000000000007eaad605a826e650 Content-Type: text/plain; charset="UTF-8" On Sun, Jun 14, 2020 at 5:37 PM Bart Schaefer wrote: > > Incidentally the _prefix behavior with the unambiguous prefix is > itself a compromise; before workers/18841 (2003-07-09) it would > alarmingly delete the entire word from the line. That's this bit of code (line numbers because gmail will probably line wrap this): 51 if [[ "$tmp" != _prefix ]] && "$tmp"; then 52 [[ compstate[nmatches] -gt 1 ]] && return 0 53 compadd -U -i "$IPREFIX" -I "$ISUFFIX" - "${compstate[unambiguous]%$suf}x" 54 compstate[list]= 55 if [[ -n $compstate[unambiguous] ]]; then 56 compstate[insert]=unambiguous 57 else 58 compstate[insert]=0 59 fi 60 return 0 61 fi The doc says: The completion code breaks the string to complete into seven fields in the order: The first field is an ignored prefix taken from the command line, the contents of the IPREFIX parameter plus the string given with the -i option. With the -U option, only the string from the -i option is used. Unless this doc is inaccurate, it's useless to even pass the -I option on line 53. Diagnosing this a bit further, I find that the reason parts of the word vanish from the command line is because _path_files has already added a completion for the directory prefix. Consequently the compadd performed by _prefix is a second one, which adds an ambiguity that was not previously present, and compadd -U apparently selects the wrong match to insert. The below patch ALMOST fixes this. The remaining problem is that in the example % ls dir1/di_r2/dir3 The result is % ls dir1/dir2_/r2/dir3 where the "2" immediately left of the cursor is highlighted. The slash isn't wanted, and any insertion at this point (including another slash) appears after the 2; any cursor motion removes the 2. This is all side-effects of the way that _path_files has done its compadd, and I haven't found a way to retroactively disable it. [I'm sure gmail is going to line-wrap this.] diff --git a/Completion/Base/Completer/_prefix b/Completion/Base/Completer/_prefix index 74be5f4..e256079 100644 --- a/Completion/Base/Completer/_prefix +++ b/Completion/Base/Completer/_prefix @@ -50,13 +50,19 @@ for tmp in "$comp[@]"; do if [[ "$tmp" != _prefix ]] && "$tmp"; then [[ compstate[nmatches] -gt 1 ]] && return 0 - compadd -U -i "$IPREFIX" -I "$ISUFFIX" - "${compstate[unambiguous]%$suf}x" - compstate[list]= - if [[ -n $compstate[unambiguous] ]]; then - compstate[insert]=unambiguous - else + # Does the following need pattern quoting on $PREFIX? + if [[ ${compstate[unambiguous]} = "$PREFIX"* ]]; then + # We completed something following the original prefix compstate[insert]=0 + compstate[to_end]= + else + # We completed something inside the original prefix + compstate[insert]=unambiguous + fi + if [[ $compstate[nmatches] -eq 0 ]]; then + compadd -U -i "$IPREFIX" -S "$ISUFFIX" - "${compstate[unambiguous]%$suf}" fi + compstate[list]= return 0 fi (( _matcher_num++ )) --0000000000007eaad605a826e650 Content-Type: text/plain; charset="UTF-8"; name="_prefix.txt" Content-Disposition: attachment; filename="_prefix.txt" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kbh254yr0 ZGlmZiAtLWdpdCBhL0NvbXBsZXRpb24vQmFzZS9Db21wbGV0ZXIvX3ByZWZpeCBiL0NvbXBsZXRp b24vQmFzZS9Db21wbGV0ZXIvX3ByZWZpeAppbmRleCA3NGJlNWY0Li5lMjU2MDc5IDEwMDY0NAot LS0gYS9Db21wbGV0aW9uL0Jhc2UvQ29tcGxldGVyL19wcmVmaXgKKysrIGIvQ29tcGxldGlvbi9C YXNlL0NvbXBsZXRlci9fcHJlZml4CkBAIC01MCwxMyArNTAsMTkgQEAgZm9yIHRtcCBpbiAiJGNv bXBbQF0iOyBkbwrCoArCoCDCoCDCoGlmIFtbICIkdG1wIiAhPSBfcHJlZml4IF1dICYmICIkdG1w IjsgdGhlbgrCoCDCoCDCoCDCoFtbIGNvbXBzdGF0ZVtubWF0Y2hlc10gLWd0IDEgXV0gJiYgcmV0 dXJuIDAKLSDCoCDCoCDCoGNvbXBhZGQgLVUgLWkgIiRJUFJFRklYIiAtSSAiJElTVUZGSVgiIC0g IiR7Y29tcHN0YXRlW3VuYW1iaWd1b3VzXSUkc3VmfXgiCi0gwqAgwqAgwqBjb21wc3RhdGVbbGlz dF09Ci0gwqAgwqAgwqBpZiBbWyAtbiAkY29tcHN0YXRlW3VuYW1iaWd1b3VzXSBdXTsgdGhlbgot IMKgIMKgIMKgIMKgY29tcHN0YXRlW2luc2VydF09dW5hbWJpZ3VvdXMKLSDCoCDCoCDCoGVsc2UK KyDCoCDCoCDCoCMgRG9lcyB0aGUgZm9sbG93aW5nIG5lZWQgcGF0dGVybiBxdW90aW5nIG9uICRQ UkVGSVg/CisgwqAgwqAgwqBpZiBbWyAke2NvbXBzdGF0ZVt1bmFtYmlndW91c119ID0gIiRQUkVG SVgiKiBdXTsgdGhlbgorIMKgIMKgIMKgIMKgIyBXZSBjb21wbGV0ZWQgc29tZXRoaW5nIGZvbGxv d2luZyB0aGUgb3JpZ2luYWwgcHJlZml4CsKgIMKgIMKgIMKgIMKgY29tcHN0YXRlW2luc2VydF09 MAorIMKgIMKgIMKgIMKgY29tcHN0YXRlW3RvX2VuZF09CisgwqAgwqAgwqBlbHNlCisgwqAgwqAg wqAgwqAjIFdlIGNvbXBsZXRlZCBzb21ldGhpbmcgaW5zaWRlIHRoZSBvcmlnaW5hbCBwcmVmaXgK KyDCoCDCoCDCoCDCoGNvbXBzdGF0ZVtpbnNlcnRdPXVuYW1iaWd1b3VzCisgwqAgwqAgwqBmaQor IMKgIMKgIMKgaWYgW1sgJGNvbXBzdGF0ZVtubWF0Y2hlc10gLWVxIDAgXV07IHRoZW4KKyDCoCDC oCDCoCDCoGNvbXBhZGQgLVUgLWkgIiRJUFJFRklYIiAtUyAiJElTVUZGSVgiIC0gIiR7Y29tcHN0 YXRlW3VuYW1iaWd1b3VzXSUkc3VmfSIKwqAgwqAgwqAgwqBmaQorIMKgIMKgIMKgY29tcHN0YXRl W2xpc3RdPQrCoCDCoCDCoCDCoHJldHVybiAwCsKgIMKgIMKgZmkKwqAgwqAgwqAoKCBfbWF0Y2hl cl9udW0rKyApKQo= --0000000000007eaad605a826e650--