GNU bug report logs - #70367
30.0.50; Inconsistent Syntax Highlighting

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>, Alan Mackenzie <acm <at> muc.de>
Cc: suratiamol <at> gmail.com, 70367 <at> debbugs.gnu.org
Subject: bug#70367: 30.0.50; Inconsistent Syntax Highlighting
Date: Sat, 13 Apr 2024 22:05:54 +0300

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: suratiamol <at> gmail.com,  70367 <at> debbugs.gnu.org
> Date: Sat, 13 Apr 2024 21:00:16 +0200
> 
> On Sat, 13 Apr 2024 20:48:28 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> >> Cc: 70367 <at> debbugs.gnu.org
> >> Date: Sat, 13 Apr 2024 20:44:37 +0300
> >> From: Eli Zaretskii <eliz <at> gnu.org>
> >>
> >> > From: Amol Surati <suratiamol <at> gmail.com>
> >> > Date: Sat, 13 Apr 2024 18:12:54 +0530
> >> >
> >> > The problem is not found in terminal emacs built from the released 29.3.tar.gz,
> >> > or with emacs running under GUI (i.e. under PGTK).
> >> >
> >> > The problem is seen with terminal emacs built from the master branch, at various
> >> > commit levels.
> >> >
> >> > Problem: When a large file (for e.g. vulkan_core.h) is opened, certain
> >> > constructs have their syntax highlighting broken. The video found at [1] shows
> >> > the behaviour. At the end of the video, one can see one instance of the problem;
> >> > the syntax highlighting for the enum constant
> >> > 'VK_STRUCTURE_TYPE_EVENT_CREATE_INFO = 10,' abruptly breaks. The entire
> >> > identifier VK_STRUCTURE_TYPE_EVENT_CREATE_INFO must be one colour. Instead,
> >> > 'VK_STRUCTURE_TYPE_EVENT_CREA' is of the expected colour, while
> >> > 'TE_INFO' is of the colour that is expected with '= 10,'. You may want to
> >> > download the video and then play it, if Google Drive plays it at a resolution
> >> > that is lower than the video's native resolution.
> >> >
> >> > Within this same session, there were other such enum constants with broken
> >> > highlighting, though they have not been captured in the video.
> >> > The termscript is attached at [2].
> >> >
> >> > The graphics session is Wayland with swaywm as its compositor; XWayland is
> >> > not enabled. The terminal emulator is 'foot'. Another terminal emulator,
> >> > 'alacritty' was also tested; the problem occurred there too.
> >> >
> >> > The problem doesn't seem to occur with small-sized files; After reducing the
> >> > vulkan_core.h to contain only around 235 lines, emacs was able to show the
> >> > (reduced) file with consistent highlighting.
> >>
> >> FWIW, I cannot reproduce this with stock Emacs 29.3 and vulkan_core.h
> >> file that I downloaded from this site:
> >>
> >>   https://github.com/KhronosGroup/dfdutils/blob/main/vulkan/vulkan_core.h
> >
> > I see now that you say you see this with the master branch, so I
> > tested that version as well, and I still don't see the problem.
> 
> I see exactly the same misfontification as the OP in the same file
> (which I happen to have on my system), as well as several more similar
> misfontifications further down in that file -- but only with c-mode from
> cc-mode.el.  With c-ts-mode I see no misfontifications in that file.
> This is with GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+
> Version 3.24.41, cairo version 1.18.0) of 2024-04-11.

Strange.  I see no misfontifications with either mode.

Alan, would you please have a look?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.