On Sun, 14 Apr 2024 at 00:35, Eli Zaretskii wrote: > > > From: Stephen Berman > > Cc: suratiamol@gmail.com, 70367@debbugs.gnu.org > > Date: Sat, 13 Apr 2024 21:00:16 +0200 > > > > On Sat, 13 Apr 2024 20:48:28 +0300 Eli Zaretskii wrote: > > > > >> Cc: 70367@debbugs.gnu.org > > >> Date: Sat, 13 Apr 2024 20:44:37 +0300 > > >> From: Eli Zaretskii > > >> > > >> > From: Amol Surati > > >> > 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. Apologies. I missed Eli's email about the C modes. My emacs build is devoid of most of the settings and features, including GUI and tree-sitter (the config command is in the original report). So it is likely that only cc-mode is affected, and not c-ts-mode. Note also that vulkan_core.h isn't special. A C source/header file with a long enough enum definition also works. Attached is a C program that generates to stdout the contents of such a header file. Opening the contents (after they are saved to a file by stdout redirection, etc.) in emacs demonstrates the problem. -Amol > > Alan, would you please have a look?