From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Troy Brown Newsgroups: gmane.emacs.bugs Subject: bug#69714: 30.0.50; ert-font-lock doesn't handle list of faces Date: Wed, 13 Mar 2024 13:48:48 -0400 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37580"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 69714@debbugs.gnu.org To: Vladimir Kazanov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Mar 13 18:49:49 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rkSjc-0009SS-94 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 13 Mar 2024 18:49:48 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rkSjJ-0001Jm-7A; Wed, 13 Mar 2024 13:49:29 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rkSjH-0001JI-Le for bug-gnu-emacs@gnu.org; Wed, 13 Mar 2024 13:49:27 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rkSjH-0002JS-DJ for bug-gnu-emacs@gnu.org; Wed, 13 Mar 2024 13:49:27 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rkSjq-00004r-IE for bug-gnu-emacs@gnu.org; Wed, 13 Mar 2024 13:50:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Troy Brown Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 13 Mar 2024 17:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69714 X-GNU-PR-Package: emacs Original-Received: via spool by 69714-submit@debbugs.gnu.org id=B69714.171035218432732 (code B ref 69714); Wed, 13 Mar 2024 17:50:02 +0000 Original-Received: (at 69714) by debbugs.gnu.org; 13 Mar 2024 17:49:44 +0000 Original-Received: from localhost ([127.0.0.1]:47389 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rkSjX-0008Vr-T9 for submit@debbugs.gnu.org; Wed, 13 Mar 2024 13:49:44 -0400 Original-Received: from mail-ed1-f52.google.com ([209.85.208.52]:53376) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rkSjW-0008Ve-C6 for 69714@debbugs.gnu.org; Wed, 13 Mar 2024 13:49:43 -0400 Original-Received: by mail-ed1-f52.google.com with SMTP id 4fb4d7f45d1cf-5687feeb1feso101980a12.2 for <69714@debbugs.gnu.org>; Wed, 13 Mar 2024 10:49:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710352141; x=1710956941; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=xiZlzIo3ivG2aOS0tjsi9US225Wx1p7GsX57/KyyhSQ=; b=w1bCHXkhtiOUVrzAiwORYqwKq0i2uuniVd+tokfQSslVU1TIOFoQ3MlkcZ+HfV3FqH ME2ahsUM++cg0P5ZyA3ApGiGHL/QPWniudcgN2yCbbfKzSLMlsL8+ejSoXXbyd9PVSvA A0bLlBtolRVU7MwS4qRF4wbwOwSmwxpuEDw5Fj0pAo71iFNXra+6ZZez3tF0HQCCmu/B 2bLnjGVPTKSnCRtwF5RjKECMsjGyM/M0ZsAh2+brCIyU6AFSVlthedea45bxZAKThxJ3 j/8KQ9VG+WXlBcfduixWX+JcK495QVJ1iVEOPa7yvU4Ifd5HtmhEzpoGlZHkdwBvQjdF V92Q== X-Gm-Message-State: AOJu0YwIHDWtHVuoMrPjQTUuoaVz3GW71Vzncq5mZizFleHoTBcqBJ70 lRCtHnAuW4zqUBRuKVsUwZiFICMZyN/lVYcyCgaA5OWBurXJOe/W0ZapfZfzS4W2ug== X-Google-Smtp-Source: AGHT+IFMSmWV02jM28W8dw9CbimUqY7zq+M3JfNAo2giKg11+CIKzDMBZf+XO7RfLlXvuOnpAauN1g== X-Received: by 2002:a17:907:a0d6:b0:a3f:4596:c3c8 with SMTP id hw22-20020a170907a0d600b00a3f4596c3c8mr9257067ejc.53.1710352140804; Wed, 13 Mar 2024 10:49:00 -0700 (PDT) Original-Received: from mail-ej1-f45.google.com (mail-ej1-f45.google.com. [209.85.218.45]) by smtp.gmail.com with ESMTPSA id s24-20020a170906a19800b00a457a55b814sm5030883ejy.73.2024.03.13.10.49.00 for <69714@debbugs.gnu.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 13 Mar 2024 10:49:00 -0700 (PDT) Original-Received: by mail-ej1-f45.google.com with SMTP id a640c23a62f3a-a46682e71a9so11809266b.3 for <69714@debbugs.gnu.org>; Wed, 13 Mar 2024 10:49:00 -0700 (PDT) X-Received: by 2002:a17:906:280d:b0:a45:c8cb:ae70 with SMTP id r13-20020a170906280d00b00a45c8cbae70mr6753798ejc.40.1710352140332; Wed, 13 Mar 2024 10:49:00 -0700 (PDT) In-Reply-To: X-Gmail-Original-Message-ID: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:281559 Archived-At: The new patch looks good to me. One other thing I thought I'd mention. I have places in my test where I want to verify that there is no font lock face. I've been able to specify "nil" for the face and that works perfectly to check this. I thought I'd mention this because I wasn't sure if it was intentional behavior, but I do find that useful. Thanks, Troy. On Wed, Mar 13, 2024 at 1:04=E2=80=AFPM Vladimir Kazanov wrote: > > Thanks a lot! > > The suggestions really do make sense. > > Here's the final integrated patch, complete with updated tests and > docs. If you're fine with it then I'll ask somebody to install it on > master. > > PS I've got to write an additional announcement in the main mailing > list inviting people to check the updated version out. > > On Wed, 13 Mar 2024 at 16:14, Troy Brown wrote: > > > > Hi Vlad, sorry for the delayed response. > > > > I haven't pushed my change which uses this package yet, as I was > > struggling to get it working and didn't want to push failing tests. I > > just discovered the package and was working on a regression test for a > > bug fix involving font locking. This seemed like the perfect reason > > to use your package. At the moment I only have this one > > work-in-progress test, but I expect to use it more going forward. > > > > I did check out your patch and for my immediate needs, it worked > > perfectly. Thanks! Additionally, I did experiment a little with the > > multi-caret functionality, which is nice as I have a use for that. I > > also experimented with the negation functionality (although I don't > > have an immediate need for that), and did notice a couple things. The > > first was that the assertion would be ignored if there was a space > > between the negation symbol and the face. Also, if the actual and > > expected faces didn't match and the negation flag was being used, it > > acted like the negation was not indicated at all and failed the test. > > I've included a diff below containing the changes I made which seemed > > to address those concerns. > > > > diff --git a/lisp/emacs-lisp/ert-font-lock.el b/lisp/emacs-lisp/ert-fon= t-lock.el > > index 06c90add9d3..1a5fe96fb09 100644 > > --- a/lisp/emacs-lisp/ert-font-lock.el > > +++ b/lisp/emacs-lisp/ert-font-lock.el > > @@ -61,6 +61,7 @@ ert-font-lock--assertion-line-re > > (group (zero-or-more (seq "^" (zero-or-more whitespace)))) > > ;; optional negation of the face specification > > (group (optional "!")) > > + (zero-or-more whitespace) > > ;; face symbol name or a list of symbols > > (group (or (regexp ert-font-lock--face-symbol-re) > > (regexp ert-font-lock--face-symbol-list-re)))) > > @@ -354,7 +355,7 @@ ert-font-lock--check-faces > > (when (symbolp expected-face) > > (setq expected-face (list expected-face))) > > > > - (when (not (equal actual-face expected-face)) > > + (when (and (not negation) (not (equal actual-face expected-face)= )) > > (ert-fail > > (list (format "Expected face %S, got %S on line %d column %d" > > expected-face actual-face line-checked column-c= hecked) > > > > > > Thanks, > > > > Troy. > > > > On Tue, Mar 12, 2024 at 4:47=E2=80=AFPM Vladimir Kazanov wrote: > > > > > > Hi, > > > > > > I've attached a patch that handles face lists, fails on files without > > > assertions and expands the parser a bit to support multiple carets pe= r > > > line. > > > > > > For faces it does the following: > > > > > > 1. Turn symbols into single element lists. > > > 2. Parses face lists from the assertions. > > > 3. Compare face lists using equas. > > > > > > Could you please check if this works for you? > > > > > > Thanks > > > > > > On Mon, 11 Mar 2024 at 08:36, Vladimir Kazanov = wrote: > > > > > > > > Hi, > > > > > > > > Thanks for reporting this! I have a bunch of ert-font-lock > > > > improvements in my local repo getting ready for submission, and can > > > > look into your suggestions as well. > > > > > > > > Do you have your unit test code somewhere in a public repo? It'd be > > > > great to think of further improvements to support your use case. > > > > > > > > Thanks, > > > > Vlad > > > > > > > > On Sun, 10 Mar 2024 at 20:33, Troy Brown wr= ote: > > > > > > > > > > I'm trying to use this package to test out my tree-sitter mode, b= ut am > > > > > running into an issue with lists of faces. It's possible that th= e > > > > > face for a location in the buffer will contain a list of 1 or mor= e > > > > > faces. For example, when I use the ":override 'prepend" keyword = in > > > > > the call to treesit-font-lock-rules, even if only a single face i= s > > > > > specified for the rule that matches that section of the buffer, t= his > > > > > will result in a list of one entry (i.e., "(face-name)"). > > > > > > > > > > When this happens, ert-font-lock fails to recognize that this mat= ches > > > > > the face "face-name" (e.g., "^ face-name" will fail to match in t= his > > > > > case). I feel the tool should recognize a list containing a sing= le > > > > > face as matching the face. Even worse however, it appears > > > > > ert-font-lock doesn't support a list of faces in the comment. I = tried > > > > > to work around the original issue by using "^ (face-name)", but t= he > > > > > tool silently ignores this, as it doesn't match the internal regu= lar > > > > > expression (which ended up allowing my test to pass without actua= lly > > > > > checking anything). > > > > > > > > > > I can't figure out a way to use this tool in its current state du= e to > > > > > its lack of support for a list of faces. Also, I find that since= it > > > > > silently ignores incorrect comment syntax (e.g., "^face-name", "^ > > > > > (face-name)"), it gives a false illusion that it's actually perfo= rming > > > > > those checks (and the checks are passing), when it's really just > > > > > ignoring them. Maybe any comment line starting with a "^" or "<-= " > > > > > should be considered an assertion check and to fail if the rest o= f the > > > > > syntax is not as expected. Maybe it should also fail the test if= no > > > > > assertion checks are found in a source file or string. > > > > > > > > > > Even if the tool would allow a list of a single face to match the > > > > > supplied face in the comment, I think it should also allow for > > > > > multiple faces to be listed in the comment. I have other places = where > > > > > multiple faces are used (e.g., "(font-lock-constant-face > > > > > font-lock-variable-name-face)" to highlight a constant variable), > > > > > which would not be testable with the current state of the package= . > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Regards, > > > > > > > > Vladimir Kazanov > > > > > > > > > > > > -- > > > Regards, > > > > > > Vladimir Kazanov > > > > -- > Regards, > > Vladimir Kazanov