From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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.2 Received: (qmail 17680 invoked from network); 28 Apr 2020 19:06:58 -0000 Received: from ns1.primenet.com.au (HELO primenet.com.au) (203.24.36.2) by inbox.vuxu.org with UTF8ESMTPZ; 28 Apr 2020 19:06:58 -0000 Received: (qmail 24700 invoked by alias); 28 Apr 2020 19:06:47 -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: 45737 Received: (qmail 2964 invoked by uid 1010); 28 Apr 2020 19:06:47 -0000 X-Qmail-Scanner-Diagnostics: from out1-smtp.messagingengine.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.2/25793. spamassassin: 3.4.4. Clear:RC:0(66.111.4.25):SA:0(-2.6/5.0):. Processed in 5.128603 secs); 28 Apr 2020 19:06:47 -0000 X-Envelope-From: d.s@daniel.shahaf.name X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at daniel.shahaf.name does not designate permitted sender hosts) X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedriedugddufedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkjghfofggtgfgsehtqh dttdertdejnecuhfhrohhmpeffrghnihgvlhcuufhhrghhrghfuceougdrshesuggrnhhi vghlrdhshhgrhhgrfhdrnhgrmhgvqeenucffohhmrghinhepgihktggurdgtohhmnecukf hppeejledrudektddrudeftddrudegjeenucevlhhushhtvghrufhiiigvpedtnecurfgr rhgrmhepmhgrihhlfhhrohhmpegurdhssegurghnihgvlhdrshhhrghhrghfrdhnrghmvg X-ME-Proxy: Date: Tue, 28 Apr 2020 19:06:01 +0000 From: Daniel Shahaf To: Zsh hackers list Subject: Re: zstyle: "more specific" patterns and *-components Message-ID: <20200428190601.0f0c8503@tarpaulin.shahaf.local2> In-Reply-To: References: <20200427101430.447e2a21@tarpaulin.shahaf.local2> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Roman Perepelitsa wrote on Mon, 27 Apr 2020 18:10 +0200: > On Mon, Apr 27, 2020 at 12:15 PM Daniel Shahaf w= rote: > > > > WDYT? >=20 > My reading of the documentation matches yours, so I also expected the > behavior you expected (which isn't the actual behavior). I also find > the documented behavior preferable to the actual behavior. >=20 I'm not sure what I prefer, actually. The documentation disagrees with the implementation, but I'm wary of changing the implementation to match the documentation because that seems like it could introduce hard-to-diagnose behaviour changes upon upgrading. I reviewed my own settings (via the output of =C2=ABzstyle=C2=BB without arguments) and found only one case in which a context could be matched by two different patterns, and even that was a bug in my zshrc (one of the patterns was insufficiently specific), so maybe I'm being overly careful here. Does anyone else have zstyle settings such that a single lookup (of a particular style under a particular context) could be matched by multiple patterns? Mikael Magnusson wrote on Mon, 27 Apr 2020 19:38 +0200: > On 4/27/20, Roman Perepelitsa wrote: > > On Mon, Apr 27, 2020 at 12:15 PM Daniel Shahaf > > wrote: > >> > >> WDYT? > > > > My reading of the documentation matches yours, so I also expected the > > behavior you expected (which isn't the actual behavior). I also find > > the documented behavior preferable to the actual behavior. > > > > My experience with zstyle is minuscule, so appraising my opinion at 2 > > cents would be too generous. >=20 > Another view is that in both cases you specified the values of two > 'elements', the fact that they are adjacent in one case shouldn't (one > could argue) affect the specificity of the pattern. (this isn't > necessarily my view). If we change the implementation to match the documentation and Alice wishes for both patterns to be considered equally specific, she will be able to achieve that by explicitly specifying all colons in the patterns: zstyle ':foo:bar:*:*' lorem world zstyle ':foo:*:baz:*' lorem hello On the other hand, if we change the documentation to match the implementation and Alice wants one of the patterns to be considered more specific regardless of the order the two patterns are defined in, she can achieve that by using a pattern other than =C2=AB*=C2=BB that matches t= he same things =C2=AB*=C2=BB would: zstyle ':foo:bar:*' lorem world zstyle ':foo:*:baz:*(|)' lorem hello (This works because the pattern =C2=AB*(|)=C2=BB is considered more specifi= c=C2=A0=E2=80=94 and gets a higher score=C2=A0=E2=80=94 than the pattern =C2=AB*=C2=BB.) dana wrote on Mon, 27 Apr 2020 13:54 -0500: > I'm guessing that * is weighted 0 so that :foo:* doesn't have more weig= ht > than :foo:, but could it work better? For example, might it work to cha= nge > the weighting to this: >=20 > 0 First consecutive *-only component (first * in :foo:*:*:bar*) > 1 Subsequent consecutive *-only component (second * in :foo:*:*:bar*) > 2 Pattern component (bar* in :foo:*:*:bar*) > 3 Literal component (foo in :foo:*:*:bar*) >=20 > ? >=20 > But i don't think my suggested change will fix the case you described. Ma= ybe > give each *-only component a weight of 1 unless it's at the very end? Hav= en't > really thought about it since i wrote that, so there might be other > considerations Firstly, shouldn't we choose between the implemented semantics and the documented semantics? Changing to a third semantics seems too xkcd.com/927/-ey to me: it risks causing breakage _both_ to people who relied on the documented behaviour and to people who relied on the implemented behaviour. I don't immediately see the rationale behind your proposed scoring. The two patterns you mention, =C2=AB:foo=C2=BB and =C2=AB:foo:*=C2=BB, don't se= em parallel to each other, since there's no possible context that can be matched by both of them. Regarding the option of changing the implementation to match the documentation, I interpret the documentation to mean a pattern that has more colons than another is always considered more specific, period. That could be implemented as a =C2=ABstruct { unsigned number_of_colons; unsigned components_specificity_score; } weight;=C2=BB with lexicographic comparisons. The following is equivalent to that =E2=80=94 diff --git a/Src/Modules/zutil.c b/Src/Modules/zutil.c index 7d9bf05d6..4868bee7e 100644 --- a/Src/Modules/zutil.c +++ b/Src/Modules/zutil.c @@ -367,6 +367,7 @@ setstypat(Style s, char *pat, Patprog prog, char **vals= , int eval) =20 if (*str =3D=3D ':') { /* Yet another component. */ + weight +=3D (1 << 16); =20 first =3D 1; weight +=3D tmp; =E2=80=94 though I'd call it only a proof of concept, since 32767=C2=A0comp= onents in a zstyle context ought to be enough for anybody :P This patch breaks the test I posted in=C2=A045722, as expected. Given the feedback so far, though, perhaps I should just commit this patch? Cheers, Daniel (I suppose we could use =C2=AB1 << (CHAR_BIT * sizeof(weight) / 2)=C2=BB to= let people on 64-bit systems use absurdly long zstyle contexts=E2=80=A6)