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=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 30567 invoked from network); 13 Oct 2021 14:21:21 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 13 Oct 2021 14:21:21 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20210803; t=1634134881; b=dp+o5QEYPre7mg4KBOKAOb9SHHu8vSAZZQqNO+0ZcO6VCyyggAzsrMyW36rN24cGgeU/vsEsyz kpf+6y6jciTmsx0Bqc1mPVPsYv1tiG3Vj3Nh6cDt4iQkbnowvfBEIAWVsRZhaDoITuFQir9J1z C3Ox3D+FhdSqWR5ysEM0vCWxLROSrRuw95I+0cRhTGei4r+waKZdVY3M1m6ob9/16E7idYJOjq mb1uVx3N265XSeAAWQlV2e20E/cpvII7OhWh4fg8XyRqiYI2UE36W7NWEBFWtpyWt/Igfq4/+Z 9p0Hb1+AQg/LMibR88o2hjuTi75rvkKy/wuhMo+vuewawg==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (mail-ua1-f52.google.com) smtp.remote-ip=209.85.222.52; dkim=pass header.d=gmail.com header.s=20210112 header.a=rsa-sha256; dmarc=pass header.from=gmail.com; arc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=zsh.org; s=rsa-20210803; t=1634134881; bh=7e4S9NAx0RAahSeZRAZID6BoOWMFESTCpwKuFFqgrFE=; h=List-Archive:List-Owner:List-Post:List-Unsubscribe:List-Subscribe:List-Help: List-Id:Sender:Content-Transfer-Encoding:Content-Type:Cc:To:Subject: Message-ID:Date:From:In-Reply-To:References:MIME-Version:DKIM-Signature: DKIM-Signature; b=ONQ/Nc4EvQ8Z06nh8mMr64jltwKUZt8EhYJvqQ0D0e6HrxV0SF5UrjlgwOgJYsNZHgM+RiYKOo qYf76kHZLi561zG5T4JL61wFzN4GxMOXZmuyQfm7H4AjD5DFEuaJmxCV2x/XcsCKwTYq6arSga WEcSrWPT/5D/RBOZVTy5dGgY/4ZLXm5rx8VMeWNJNhLQlL9ECIfr2kkjn6qizW4ixBroDjDT8Z aqVTRf70Jsp8zyUONfwP4KCsXbva4gQTJC0CKa1EY56zEqs//SPei7UFCbHakTh64oqDbD7q/G VggWG8Elt8Ss3Yu21rRZJ42YvFmmZbLky77Oe7CB8CLDBA==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zsh.org; s=rsa-20210803; h=List-Archive:List-Owner:List-Post:List-Unsubscribe: List-Subscribe:List-Help:List-Id:Sender:Content-Transfer-Encoding: Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:References: MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=mJ0Ap8M+eK2CaEkMbBvNWy8Y+gnhGxKzzJxGK5LBoyg=; b=gdvWhCjiDpp2eoHsaWO3EXfwza tMsLyYLhzlu/swU0m4AH9occNuLkkHSySPyXmV/VgDnVRoO6oNzeip+rAWxBiI/QkYRZL9HQZWEzO H3DHvr32lspiiwmXOSznY9bc8/cKWyVYaIpJ7BM7EPt6ELdkNJb1xaKaf+ulVZBEV2lBtPMuivN4L 2zvB5KgBQlxZ0VKt/ViCH3c12408S7jhJyIj22d8SeYLmY1gN5n06FI2kreTeQx72C0flHdC+VPv7 IfRPwwEMRJVvrVH2y2CWg/vLvB1FxGYKnencirk8ZCxctzUH9nFhBPDEeCL1BKx3k0AM4F9kWcDR5 JvKT5gRg==; Received: from authenticated user by zero.zsh.org with local id 1maf8C-0008nj-Oy; Wed, 13 Oct 2021 14:21:20 +0000 Authentication-Results: zsh.org; iprev=pass (mail-ua1-f52.google.com) smtp.remote-ip=209.85.222.52; dkim=pass header.d=gmail.com header.s=20210112 header.a=rsa-sha256; dmarc=pass header.from=gmail.com; arc=none Received: from mail-ua1-f52.google.com ([209.85.222.52]:36615) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) id 1maf7e-0008UM-Af; Wed, 13 Oct 2021 14:20:49 +0000 Received: by mail-ua1-f52.google.com with SMTP id e10so198466uab.3 for ; Wed, 13 Oct 2021 07:20:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=mJ0Ap8M+eK2CaEkMbBvNWy8Y+gnhGxKzzJxGK5LBoyg=; b=HMOSwGPL2PrdBUXCww0L5KL9ob11iSsBx7mXW1/MHRxewoK9XxbFTvDWIwE9m1a9Lj ONz4WzPWZ4YndyuDhraywWCGfcUQhRPI9NzFW3jEX08fM3EB+7bCtS7j2W/GidE623+M R5ldiI4C54Lp34NXbJdy0+uzbE/epSl4KdMKVeAmDuUFUM0o1JgZdHxvaPYj4lphqVhl 4a8zEsa+3MjdJuqiaFBh0ZTruG4N7CJ6C1qaKH3Ez/tkQ74/12B5f/Y2sg02JjIg31QC ZdDUvHGz8kvuS5M/8GMAc65wT3946+2VIJaJJ8XiUtLden8hBcfTJ+ymyQ+KElt6ZASs XhwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=mJ0Ap8M+eK2CaEkMbBvNWy8Y+gnhGxKzzJxGK5LBoyg=; b=pAP09tI9RcBYr1OlKGIRqhqa2wQdqeTL2N1bXdOhfsS9GE3fLWSpGBQFNGoKpvwM+j fCIToYvZMFih+cc3IEGeYZwKK7ln5ASK744JEqrRh2B0rg43K9GMSUghFo6RdoR5oSoP zrjJJuDlcK3yW4uBc716J8tU1qkSghoAfOiEkEzDCZ7UBoOr7VsXyf0PJBlakATYeHcQ 0wmYF7pA0maAD3k0R4wGNUOybEs6on4nvvR0gXsrYJ0X7N5E9hvtxDMo0H3vhkufg5le M/uMuPe0mOGyG0H11eo13UiFPxTwiZ0bOop34MiscqVCHNomr2YtJT9JA2GV4R6N5G0T aoNQ== X-Gm-Message-State: AOAM5325HE2+xwp9WJ6tc6gSl9Il+gyirz0CATgNbD2m/rgQtD5CyNEt y6yDQeHRQUvolqAAdurGscxIEBnvjmLX9kwe7cc= X-Google-Smtp-Source: ABdhPJyV7EJ23PKmovH0hw1Djf3DSMfagPDa+aCVkvzo15uz01FiQzhzId0gNXKMsQ5q6Rq+YcPoG5KqHXdyTFU5aB4= X-Received: by 2002:a05:6102:3a12:: with SMTP id b18mr39179434vsu.27.1634134845039; Wed, 13 Oct 2021 07:20:45 -0700 (PDT) MIME-Version: 1.0 References: <20211012152532.GC17948@tarpaulin.shahaf.local2> In-Reply-To: From: Marlon Richert Date: Wed, 13 Oct 2021 17:20:09 +0300 Message-ID: Subject: Re: [RFC] Add xfail tests for || form of completion matchers To: Bart Schaefer Cc: Daniel Shahaf , Zsh hackers list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Seq: 49482 Archived-At: X-Loop: zsh-workers@zsh.org Errors-To: zsh-workers-owner@zsh.org Precedence: list Precedence: bulk Sender: zsh-workers-request@zsh.org X-no-archive: yes List-Id: List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: List-Archive: On Wed, Oct 13, 2021 at 8:08 AM Bart Schaefer w= rote: > > On Tue, Oct 12, 2021 at 8:26 AM Daniel Shahaf wr= ote: > > > > Marlon Richert wrote on Tue, Oct 12, 2021 at 15:08:46 +0300: > > > On Mon, Oct 11, 2021 at 5:34 PM Marlon Richert wrote: > > > > > > > > The tests show how :||=3D matchers should behave in order to provid= e > > > > completion features that cannot be implemented with :|=3D matchers. > > > > Would this be backwards compatible? No, it would not, but that's unavoidable, since at present, the :||=3D matchers don't work correctly. Please see my and Oliver's comments in the thread of users/27228. On the plus side, there are only two lines in the Zsh codebase where :||=3D matchers are used, in _ssh and _x_color. It won't require much work to convert those. > In particular, with the exception of specific bug regression tests, > all the tests using || matchers have been converted to xfails. > Shouldn't there still be some generic tests of the (functionally > correct subset of) the current behavior of || ? There was exactly one non-regression test using :||=3D matchers, =C2=ABDocumentation example using "r:[^A-Z0-9]||[A-Z0-9]=3D** r:|=3D*"=C2= =BB, and unfortunately, that one will no longer pass as written. However, I will see if I can find some cases for which the current implementation works correctly and add tests for them. > And, do you think any > of the regression tests would begin to fail if the xfail tests begin > to succeed? There are four regression tests that incorporate one or more :||=3D matchers. I investigated them and this is what I found: * Bug from workers 11081 is about the cursor jumping back and forth. I was able to remove all three :||=3D matchers from the test without breaking it. * Bug from workers 11586 is about characters getting deleted while inserting the "unambiguous" substring. Here, I was not able to remove or replace the :||=3D matcher and still get the same output. This one might break, but most of the output it expects is actually not relevant to the bug it is testing. * Test from workers 13320 is about cursor positioning. I was able to remove the :||=3D matcher from the test without breaking it. * Second test from workers 13345 is about a character getting deleted. I was able to replace the :||=3D matcher with a :|=3D matcher without breaking the test. On Tue, Oct 12, 2021 at 6:25 PM Daniel Shahaf wrot= e: > > Thanks. I have never found that section easy to follow. You're not the only one. ;) > Could you confirm that the text which the docs patch deletes or changes > was all confirmed correct (even if perhaps unclear)? I'm concerned > about us possibly changing dense, accurate docs into clear, less-accurate > docs. The original docs were vague and ambiguous on many points, and even self-contradictory on some. > Case in point: The incumbent docs say that the coanchor is matched only > against the trial completion, but the new docs say something else. If > that's an intentional change, it needs to be called out explicitly in > the log message. Yes, that's intentional. I'll add it to the commit message. > In the man page rendering on my system, itemiz()'s bullet is vertically > aligned with the parent item()'s text. I can confirm that this indeed looks wrong. Do you know what I should use to get them indented properly? Or if that's not possible, I can add a ifzman check to format the text without bullets in the man page. However, I would at least like to keep them in the html page, because it helps make the text clearer. On Wed, Oct 13, 2021 at 7:57 AM Bart Schaefer w= rote: > > On Tue, Oct 12, 2021 at 8:26 AM Daniel Shahaf wr= ote: > > > > Could you confirm that the text which the docs patch deletes or changes > > was all confirmed correct (even if perhaps unclear)? > > For example, this part is misleading: > > > > +By default, characters in the string to be completed (referred to he= re as the > > > +command line) map only onto identical characters in the list of matc= hes > [...] > > > +missing characters are inserted only at the cursor position, if the = shell > > > +option tt(COMPLETE_IN_WORD) is set, or at the end of the command lin= e, > > It's at the end of the current word, not the end of the command line. > The old wording nearly always says "string on the command line" which > is only somewhat better; if it's going to be completely rewritten to > drop "string on the", the phrase "command line" should become more > precise. "Incomplete word" perhaps? The use of "command line" in this fashion is from the original text; it is used there about half of the time without the addition of "string". However, I agree that it's ambiguous. I'm fine replacing it with "incomplete word" (unless we come up with a better term). > > > +corresponding tests are applied to both characters, but they are not= otherwise > > > +constrained; any matching character in one set goes with any matchin= g character > > > +in the other set: this is equivalent to the behaviour of ordinary ch= aracter > > > +classes. > > What's an "ordinary" character class? That is, what ordinary context > is implied? I didn't write that paragraph; it was already present in the original doc. I just moved it around. > > > +xitem(tt(l:)var(anchor)tt(|)var(lpat)tt(=3D)var(tpat)) > > > +xitem(tt(L:)var(anchor)tt(|)var(lpat)tt(=3D)var(tpat)) > > > +xitem(tt(r:)var(lpat)tt(|)var(anchor)tt(=3D)var(tpat)) > > > +item(tt(R:)var(lpat)tt(|)var(anchor)tt(=3D)var(tpat))( > > > +Let any command line substring, which is left/right-adjacent (respec= tively) to > > > +a substring matching var(anchor) and which matches var(lpat), be com= pleted to > > > +any trial completion substring, which > > > +startitemize() > > > +itemiz(\ > > > +is adjacent to the same substring and which > > Unclear whether "the same substring" refers to "any command line > substring" or to "a substring matching anchor". I believe you mean > the former (or perhaps the larger substring composed of both of the > former)? Best to specify. Will do. > I believe the rest of the explanations are correct, but it would be > good if Oliver confirms. > > Did you remove the assorted other examples because there is a problem wit= h them? I split them into parts and moved each part directly beneath the matcher(s) it uses. This makes the matchers easier to understand and allows the examples to be explained with less text.