From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Bill Sacks Newsgroups: gmane.emacs.bugs Subject: bug#56818: 28.1; c-mode font-lock issues in Emacs 28 Date: Fri, 29 Jul 2022 14:23:59 -0600 Message-ID: <343d4736-8c6e-eacb-5d7f-3ae10ef486e6@ucar.edu> References: <83edy48nsq.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------4685E74C3D3540B830CD028A" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39025"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:52.0) Gecko/20100101 PostboxApp/7.0.56 Cc: Eli Zaretskii , 56818@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jul 29 22:25:10 2022 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 1oHWXm-0009xh-8K for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 29 Jul 2022 22:25:10 +0200 Original-Received: from localhost ([::1]:52434 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oHWXl-00083Z-6J for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 29 Jul 2022 16:25:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52784) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oHWXe-00083N-3D for bug-gnu-emacs@gnu.org; Fri, 29 Jul 2022 16:25:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:43781) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oHWXd-0002bN-Q4 for bug-gnu-emacs@gnu.org; Fri, 29 Jul 2022 16:25:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oHWXd-0000xy-IO for bug-gnu-emacs@gnu.org; Fri, 29 Jul 2022 16:25:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Bill Sacks Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 29 Jul 2022 20:25:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56818 X-GNU-PR-Package: emacs Original-Received: via spool by 56818-submit@debbugs.gnu.org id=B56818.16591262513637 (code B ref 56818); Fri, 29 Jul 2022 20:25:01 +0000 Original-Received: (at 56818) by debbugs.gnu.org; 29 Jul 2022 20:24:11 +0000 Original-Received: from localhost ([127.0.0.1]:33530 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oHWWo-0000wa-71 for submit@debbugs.gnu.org; Fri, 29 Jul 2022 16:24:11 -0400 Original-Received: from mail-oi1-f177.google.com ([209.85.167.177]:33503) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oHWWl-0000wK-Vp for 56818@debbugs.gnu.org; Fri, 29 Jul 2022 16:24:08 -0400 Original-Received: by mail-oi1-f177.google.com with SMTP id n133so6982796oib.0 for <56818@debbugs.gnu.org>; Fri, 29 Jul 2022 13:24:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucar-edu.20210112.gappssmtp.com; s=20210112; h=content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:from:to:cc; bh=qq6uuVz/QXY/w9QA8kAdHdk6gOs4H1xkUbcXqleu6s8=; b=dK45iiT0a7SWfOa/RbL0cwFdb5rU25oM+e8VJNzXg+bRlewEJFfuSpFgdGv5auY7/m gkpdOrUL4eqkPEXTn3Zq8RUAPEKQjfWgC9dnyd0Hso4vbCLj0h16TkSkwbMOXsx4hEsS cCx0r+J0TQ5d1S8UbNhdTpaLzmoi9JpTOEQsrze6UDirzSEVpLtXkNnibzgC5yx8+jsk dfqJChyFsJanR++5Xgw0IVdB06maPf5AsedSrQyMKN+/hQiQk2WXAGfSSLsLLatJp8B9 W8Baxve2kWFLTfS4tDY7fHddRKbE5TSZWkDXITwz/nF+QTuR1kF3w26LWt27izZobzI/ PgUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:x-gm-message-state:from:to :cc; bh=qq6uuVz/QXY/w9QA8kAdHdk6gOs4H1xkUbcXqleu6s8=; b=Vj7UD8eMJHlSLb9ebe6rObMhfoSm9qYgxCkIxqYHLctTviAGTL+E0CCtrwlUOxkf5y M38Hd2yQVN6fTAeEkduox6n8WhBzleLKwe3ghXtDjLcfvXqyq3QwPBmX68VOIvtIYzM6 pAJwsrJBo5WGE3vYIIM0Ows2BQJaFf6LwErhTjX49d2jPWtVRYQFZLbwENiysoiFq7Bw vHh5Tjnhjc441ni1ANYxcO8SgAS24wMTQsdDZ4T+8TLjVfH5Rw6XIhxxxWjwsqzigKhH 69I6z3yOLH6gnufcrAUhY6Ito1Gig/m70E5t1a/ZJczYNfJ5BTwrTA3r7QUb89OSWOZ9 1qxA== X-Gm-Message-State: AJIora9un44EdIaKaZgIqevkPytgPDYbL1l4egH2OAm8GPWuujUxrBbS 6RRc15ajpwN5qXJ87nhXcWHAnAR/dWGO8H5NYI3YnXOFaFb5D25mDWzrmWI/O0lEu+/WLwgY8he WS70mzk0KCLyugfs+wFUU8UFsySbkYmJ9RpFobRWTqrjHlPkEdNoko2MJYczL2g== X-Google-Smtp-Source: AGRyM1ssLE97tdqrkL96MNko5CMTnDg998W5L7ciV2wU2wQZcm5VcanwQFkSCShJG1Xawupg1jiwuw== X-Received: by 2002:a05:6808:4ca:b0:33a:7280:b90 with SMTP id a10-20020a05680804ca00b0033a72800b90mr2649778oie.248.1659126242039; Fri, 29 Jul 2022 13:24:02 -0700 (PDT) Original-Received: from [192.168.0.79] (97-118-158-229.hlrn.qwest.net. [97.118.158.229]) by smtp.gmail.com with ESMTPSA id d184-20020aca36c1000000b00339e6212ea7sm1263738oia.55.2022.07.29.13.24.01 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Jul 2022 13:24:01 -0700 (PDT) In-Reply-To: Content-Language: en-US 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" Xref: news.gmane.io gmane.emacs.bugs:238222 Archived-At: This is a multi-part message in MIME format. --------------4685E74C3D3540B830CD028A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thank you very much for this quick reply and fix, Alan! Yes, from a couple of tests, this fixes the issue I was having (and stops me from getting distracted by constantly changing fontification while writing a comment – thank you!). I'll let you know if I notice any remaining issues. This does not fix the issue I'm seeing with fontification of variable names in python-mode (which also appears to be an Emacs 28 regression), but given that this fix is specific to cc-engine, the python-mode issue is apparently different. That one seems a little harder to reproduce, so it may take me a while to develop a simple reproducer for it, especially since I haven't been doing much python programming recently. However, please let me know if you would like me to prioritize opening an issue for that one: I can do so sooner if it would be helpful. Thanks again, Bill Alan Mackenzie wrote on 7/29/22 11:44 AM: > Hello, Bill and Eli. > > On Fri, Jul 29, 2022 at 08:56:21 +0300, Eli Zaretskii wrote: >>> From: Bill Sacks >>> Date: Thu, 28 Jul 2022 14:32:09 -0600 > First of all (Bill), thanks for taking the trouble to report this bug, > and thanks even more for cutting the test case down to the short fragment > in your screenshots. > >>> Starting with Emacs 28, I have been seeing font-lock issues when >>> editing C and C++ code. The situation where I see this the most >>> (though I'm not sure if it's the only situation) is when I am writing >>> a comment and currently have a space at the end of the comment line: >>> in this situation, the fontification of a variable name or function >>> name on the next line becomes broken until I type a non-space >>> character to end the current line. >>> The attached screen shots illustrate the problem: nospaces.png shows >>> the correct fontification; space_before_var.png and >>> space_before_function.png show that variable and function names lose >>> their fontification when there is a space at the end of the previous >>> comment line. Running M-x font-lock-fontify-buffer temporarily fixes >>> the issue. >>> The problem occurs even when using emacs -Q. I have tried the latest >>> emacs28 pretest and the latest nightly build available from >>> emacsformacosx (though with my customizations – NOT with emacs -Q) >>> and those also exhibit the problem. The latest emacs27 from >>> emacsformacosx does NOT have this issue. > This is a coding bug in an optimisation from March 2020, where the > complaint was that scrolling over a 2,000 line macro was slow. The fix > neglected the possibility of spaces at the end of comment lines. > > Could you please apply the following patch in your Emacs-28.1, byte > compile the file ..../lisp/progmodes/cc-engine.el, then try out the > result on your real code. (If you want any help with the patching or > byte compiling, feel free to send me private mail.) Then please confirm > that the bug is fixed, or tell us how it's not fixed. Thanks! > > > > diff -r 9c649274b259 cc-engine.el > --- a/cc-engine.el Tue Jul 26 20:08:39 2022 +0000 > +++ b/cc-engine.el Fri Jul 29 17:25:16 2022 +0000 > @@ -1679,9 +1679,13 @@ > Return the result of `forward-comment' if it gets called, nil otherwise." > `(if (not comment-end-can-be-escaped) > (forward-comment -1) > - (when (and (< (skip-syntax-backward " >") 0) > - (eq (char-after) ?\n)) > - (forward-char)) > + (let ((dist (skip-syntax-backward " >"))) > + (when (and > + (< dist 0) > + (progn > + (skip-syntax-forward " " (- (point) dist 1)) > + (eq (char-after) ?\n))) > + (forward-char))) > (cond > ((and (eq (char-before) ?\n) > (eq (char-before (1- (point))) ?\\)) > > > > >> Alan, this seems to be a regression in Emacs 28, so could you please >> look into it? > Eli, Do I understand you want the fix in the release branch? > --------------4685E74C3D3540B830CD028A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Thank you very much for this quick reply and fix, Alan! Yes, from a couple of tests, this fixes the issue I was having (and stops me from getting distracted by constantly changing fontification while writing a comment – thank you!). I'll let you know if I notice any remaining issues.

This does not fix the issue I'm seeing with fontification of variable names in python-mode (which also appears to be an Emacs 28 regression), but given that this fix is specific to cc-engine, the python-mode issue is apparently different. That one seems a little harder to reproduce, so it may take me a while to develop a simple reproducer for it, especially since I haven't been doing much python programming recently. However, please let me know if you would like me to prioritize opening an issue for that one: I can do so sooner if it would be helpful.

Thanks again,
Bill

Alan Mackenzie wrote on 7/29/22 11:44 AM:
Hello, Bill and Eli.

On Fri, Jul 29, 2022 at 08:56:21 +0300, Eli Zaretskii wrote:

From: Bill Sacks <sacks@ucar.edu>
Date: Thu, 28 Jul 2022 14:32:09 -0600

First of all (Bill), thanks for taking the trouble to report this bug,
and thanks even more for cutting the test case down to the short fragment
in your screenshots.


Starting with Emacs 28, I have been seeing font-lock issues when
editing C and C++ code. The situation where I see this the most
(though I'm not sure if it's the only situation) is when I am writing
a comment and currently have a space at the end of the comment line:
in this situation, the fontification of a variable name or function
name on the next line becomes broken until I type a non-space
character to end the current line.


  
The attached screen shots illustrate the problem: nospaces.png shows
the correct fontification; space_before_var.png and
space_before_function.png show that variable and function names lose
their fontification when there is a space at the end of the previous
comment line. Running M-x font-lock-fontify-buffer temporarily fixes
the issue.


  

  
The problem occurs even when using emacs -Q. I have tried the latest
emacs28 pretest and the latest nightly build available from
emacsformacosx (though with my customizations – NOT with emacs -Q)
and those also exhibit the problem. The latest emacs27 from
emacsformacosx does NOT have this issue.


  
This is a coding bug in an optimisation from March 2020, where the
complaint was that scrolling over a 2,000 line macro was slow.  The fix
neglected the possibility of spaces at the end of comment lines.

Could you please apply the following patch in your Emacs-28.1, byte
compile the file ..../lisp/progmodes/cc-engine.el, then try out the
result on your real code.  (If you want any help with the patching or
byte compiling, feel free to send me private mail.)  Then please confirm
that the bug is fixed, or tell us how it's not fixed.  Thanks!



diff -r 9c649274b259 cc-engine.el
--- a/cc-engine.el	Tue Jul 26 20:08:39 2022 +0000
+++ b/cc-engine.el	Fri Jul 29 17:25:16 2022 +0000
@@ -1679,9 +1679,13 @@
 Return the result of `forward-comment' if it gets called, nil otherwise."
   `(if (not comment-end-can-be-escaped)
        (forward-comment -1)
-     (when (and (< (skip-syntax-backward " >") 0)
-		(eq (char-after) ?\n))
-       (forward-char))
+     (let ((dist (skip-syntax-backward " >")))
+       (when (and
+	      (< dist 0)
+	      (progn
+		(skip-syntax-forward " " (- (point) dist 1))
+		(eq (char-after) ?\n)))
+	 (forward-char)))
      (cond
       ((and (eq (char-before) ?\n)
 	    (eq (char-before (1- (point))) ?\\))






  
Alan, this seems to be a regression in Emacs 28, so could you please
look into it?


  
Eli, Do I understand you want the fix in the release branch?











--------------4685E74C3D3540B830CD028A--