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,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 30979 invoked from network); 13 Oct 2021 19:38:20 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 13 Oct 2021 19:38:20 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20210803; t=1634153900; b=nG4znMgcjJEC6FfGnZKwIyQf3yHl5ZIypt12IkWtPJqVdU0I3302SaoOJK20LFa4K2Zev38Yc+ MDmwTnE/E7ABfEi5kXQqcLEQnSiU/Og2seA3ONJsaUS2rOtauga4BiEHdsZRgXpzQYLwWEGNDp KqCB2ifIgAzPE+4XqVX0AbDPZ6TudcZbQmYaI6ZZQmcfOQxxlDTKZrV/KwD0j8iAvOoL1RUa4h KdNA63Llni0x9K+ZVLZ67BRJGO6mba6n7NPFhNwYWpP1ddu31O2y4Js4zIxi4PLsiDSOEr01uq c7J9gLeqEdFZSUWc4ok8JmUXwn/GCGpWa6hFZ7d2xFYg/A==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (out3-smtp.messagingengine.com) smtp.remote-ip=66.111.4.27; dkim=pass header.d=daniel.shahaf.name header.s=fm1 header.a=rsa-sha256; dkim=pass header.d=messagingengine.com header.s=fm1 header.a=rsa-sha256; dmarc=none header.from=daniel.shahaf.name; arc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=zsh.org; s=rsa-20210803; t=1634153900; bh=rDs9C6/qlaR1oLh4dai8p1ABaKzb7/r7YOa4DcpuNho=; h=List-Archive:List-Owner:List-Post:List-Unsubscribe:List-Subscribe:List-Help: List-Id:Sender:In-Reply-To:Content-Transfer-Encoding:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:DKIM-Signature: DKIM-Signature:DKIM-Signature; b=MTJ6j4QVOzvIHzK2++DAvaRUI6yn8JClvV8DrRc207x0LHb6rExxCbRHCXw0tRStjTRer3ciLG ipwClik/5N5krynPkSY0n7a+H7X9bNUICK2Crbt51njdFRoE7okTm0EB1YuGCWHQIta6/bzrK0 CpOLPJ4uJNto1/w7w8lYogWriCkgj8ZMujxmoHPMNJ2djEKspCfyAYqslHOqu8YrIgWBNGoANz q4Z5YHOeQtGFxmqvfarHwKPcm8kYVZprs3y6R7L94o2S+Y2HyeLKAbRM06a2h/0YoR05gtMe4r 95iRrIZnF0TsvUd5hSYYxGhGMvb/fkP+8/1on3plM5uE7A==; 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:In-Reply-To:Content-Transfer-Encoding :Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID; bh=EKXSlVBkLaer+pf2WT2H/CLJHMYeIRRkbHFXsgIJ/Fo=; b=jPxQtLJxPK9Z9MKEs6TWl659hR /dexhU0qSKdgLt5VCLcZpLK/IuZI21QYFyJzaXvSlGEvDFRNCMOyJIkj1yAKFnOmWeUuStI5RGOdy iQacSNx7GkTx5doPF4MqUBXcljy1VzgO12Kpl+GegzHxzYAQpQM8vhEoZFCAYXzDLIeO40lMQ+nP4 LeyYSLcE0sNErXQL3NGxb3kqXHrad69rbb/HUXqOZwk7lVHJwrV3ci9tnUHIQFh+lwimx/DDHW48S LeXSMgLQyhJFGcPDqhmRgJOqftjxJ0eTmxVM0IzcXvDNYdHUqowHraRtSygayNWQAE8vN/a9mgzDQ HThM7Qtw==; Received: from authenticated user by zero.zsh.org with local id 1mak4x-000Nyq-Tu; Wed, 13 Oct 2021 19:38:19 +0000 Authentication-Results: zsh.org; iprev=pass (out3-smtp.messagingengine.com) smtp.remote-ip=66.111.4.27; dkim=pass header.d=daniel.shahaf.name header.s=fm1 header.a=rsa-sha256; dkim=pass header.d=messagingengine.com header.s=fm1 header.a=rsa-sha256; dmarc=none header.from=daniel.shahaf.name; arc=none Received: from out3-smtp.messagingengine.com ([66.111.4.27]:44055) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_256_GCM_SHA384:256) id 1mak4P-000Nh7-6R; Wed, 13 Oct 2021 19:37:46 +0000 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 6FFD55C0134; Wed, 13 Oct 2021 15:37:44 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Wed, 13 Oct 2021 15:37:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= daniel.shahaf.name; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:content-transfer-encoding :in-reply-to; s=fm1; bh=EKXSlVBkLaer+pf2WT2H/CLJHMYeIRRkbHFXsgIJ /Fo=; b=tWeB0YN/0LP9FbQAt/nvVYqY0yYumtYNOylHskDybLnuJ5ciSeYtuA3I xeo3zvv0UlN/Yiv/VCQyC3ed0MmlbRSrXglVArCCb09Rhz/CI+aZG0+kCpKSakif mEvWfMi3t9lYFODC/fnKjPodqo4pX5Ac0aztwyzs1SvwDZsABroI9WJKk7ITz5Pw +yuY2p8JzNpbNWwY12B0p6CGd4z28uJakz0sxbTywUrRsvLCjRymvF4KxmSuJC61 ZTISsO8KzYr4P1c+IBLJYRUkpk7ENOxArDxuP09+CSS4FjEhns4Aa9ZmpmCmxFZ+ KIdCnjGKrvYW6JsfPtGlWXcugz3atg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=EKXSlVBkLaer+pf2WT2H/CLJHMYeIRRkbHFXsgIJ/ Fo=; b=JKVXwA6NmtRn8PqsP4ICMHFUObOd5n/TX5gzp5808KzG5aJrDtS6LqgUt yw8pVCExyop0CkxXKH2478qrmdQxFOMMaGgd1yyVGIuiwbeID6KtFBquxA+9VKV4 DL1GESX0m00SFbQFTS6I7X4DON8z0J/J+qfwOuIXvbtVrS2bZTV/7bDwVMfLDXk/ 8afCFI7s/iY6cJo3PNKx29EsRtw9XrLoiUoy+oVBZkEcOxZxaowkQNOlisMbtgbU 2+viXRDHkxiqfOz7jJGJSUdj7OX/FynaK4BXyMfesVPy74/++5zodz2fTRRCzdy3 kTac7rBfPmN3xrK5es3SOt5Cjx0NQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvddutddgudefjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvuffkfhggtggugfgjfgesthektddttderjeenucfhrhhomhepffgr nhhivghlucfuhhgrhhgrfhcuoegurdhssegurghnihgvlhdrshhhrghhrghfrdhnrghmvg eqnecuggftrfgrthhtvghrnhepgfekgfefjefgvddvgfdutdelleekvdefteeitdduhfev veevudfhvdevfeefvdeunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepugdrshesuggrnhhivghlrdhshhgrhhgrfhdrnhgrmhgv X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 13 Oct 2021 15:37:44 -0400 (EDT) Received: by tarpaulin.shahaf.local2 (Postfix, from userid 1005) id 4HV2qm5tD0z4qb; Wed, 13 Oct 2021 19:37:40 +0000 (UTC) Date: Wed, 13 Oct 2021 19:37:40 +0000 From: Daniel Shahaf To: Marlon Richert Cc: Zsh hackers list Subject: Re: [RFC] Add xfail tests for || form of completion matchers Message-ID: <20211013193740.GA27436@tarpaulin.shahaf.local2> References: <20211012152532.GC17948@tarpaulin.shahaf.local2> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Seq: 49483 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: Marlon Richert wrote on Wed, Oct 13, 2021 at 17:20:09 +0300: > On Wed, Oct 13, 2021 at 8:08 AM Bart Schaefer wrote: > > > > On Tue, Oct 12, 2021 at 8:26 AM Daniel Shahaf wrote: > > > > > > 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 :||= matchers should behave in order to provide > > > > > completion features that cannot be implemented with :|= matchers. > > > > > > Would this be backwards compatible? > > No, it would not, but that's unavoidable, since at present, the :||= > matchers don't work correctly. Please see my and Oliver's comments in > the thread of users/27228. > Care to give a more specific pointer? As in, specific cases where the incumbent documentation doesn't match the implementation? users/27228 itself reads rather along the lines of "let's re-design the feature retroactively". If you want to clarify the documentation of the feature as designed, kudos. If you want to increase test coverage, more kudos. If you want to throw out the existing documentation and implementation and reimplement things differently… that's not to be done lightly, notwithstanding that you went the right way about proposing it (first clarifying the status quo, then posting docs and XFail tests). > On the plus side, there are only two lines in the Zsh codebase where > :||= matchers are used, in _ssh and _x_color. It won't require much > work to convert those. That's not how it works. Documented semantics are API promises that should be presumed to be used in the wild. Any change that may break anybody's proverbial spacebar heating is an incompatible change and should be treated accordingly (avoided if possible, and failing that, clearly documented for upgraders, designed with a reasonable failure mode for old code on new zsh, etc.). When you give your house key to a trusted, you can always change the lock and give the friend a new key. However, user code isn't like a house key. User code is more closely analogous to public roads in that old story about how the width of a car was basically determined by the Romans (because cars had to be compatible with existing roads): it exists, it can't be changed, it must be compatible with; it's a design constraint. > > 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 :||= matchers, > «Documentation example using "r:[^A-Z0-9]||[A-Z0-9]=** r:|=*"», and > unfortunately, that one will no longer pass as written. A patch that breaks a documentation example is the archetype of an incompatible change. Is there no alternative to that? Can't you add a new syntax? It can be as simple as «-M 'v2: …'» (that's pretty common in standards that retrofit themselves into DNS TXT records, for instance). > However, I will see if I can find some cases for which the current > implementation works correctly and add tests for them. Thanks. > > 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 :||= > 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 :||= matchers from the test without > breaking it. The test isn't a unit test of :||=, where one would expect the output to change when :||= is removed. The test is a regression test that's supposed to catch instances of a bug that could be reproduced only by one person and only intermittently. For such tests, changing their code in any way might make them no longer test for the bug they claim to. > * Bug from workers 11586 is about characters getting deleted while > inserting the "unambiguous" substring. Here, I was not able to remove > or replace the :||= matcher and still get the same output. This one > might break, Ack. > but most of the output it expects is actually not relevant to the bug > it is testing. FWIW, the reply to 11586, 11634, mentions CamelCase briefly. > * Test from workers 13320 is about cursor positioning. I was able to > remove the :||= matcher from the test without breaking it. So what? The question isn't whether users who have used :||= could have written their code without it. The question is whether users who have used :||= would see a behaviour change if :||='s semantics were changed in the manner proposed. > * Second test from workers 13345 is about a character getting deleted. > I was able to replace the :||= matcher with a :|= matcher without > breaking the test. > Ditto. > On Tue, Oct 12, 2021 at 6:25 PM Daniel Shahaf wrote: > > 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. Concrete examples, please? users/27228 is a long thread, and the patch itself is 500 80-character lines long. > > 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. Thanks, but again, that was just a case in point. You need to identify all such cases, or better yet, split the patch into a series of small, reviewable changes. That's always a good idea, and more so for changes that are _a priori_ controversial (in this case, due to being backwards incompatible). > > 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? No, sorry. You might want to look in zman.yo and ztexi.yo to see if we define or redefine startitem(), item(), startitemize(), or itemiz(). If not, then it might be some issue that can be reproduced with yodl/nroff/man alone, i.e., not an issue specific to zsh's yodl code. > Or if that's not possible, I can add a ifzman check to format the text > without bullets in the man page. Or with ASCII bullets. > However, I would at least like to keep them in the html page, because > it helps make the text clearer. Sure.