I mentioned the actual length of the line FTR, not as an excuse for unbearably slow display. Ah, ok, sorry, I thought you were disagreeing that the line was not that long. :) It's nice to have that fixed, if it isn't too complex, but in general visiting such a file as C file is not a reasonable thing to do. Right, but I didn't know this was what ?format=TEXT downloaded from googlesource.com, so if I'd had unsaved buffers I would have been screwed. Luckily I didn't lose work (except having to reopen a bunch of files to get back to where I was). Like I said, try Emacs 29, where this should be fixed. I just upgraded to 28 from 26, which took a while! :) Anyway, I'll give it a shot sometime, but it sounds like you and Gerd are having different experiences with this file? Chris ------ Original Message ------ From: "Eli Zaretskii" To: "Chris Hecker" Cc: gerd.moellmann@gmail.com; 59038@debbugs.gnu.org; acm@muc.de Sent: 2022-11-05 02:30:58 Subject: Re: bug#59038: loading this base64 file makes emacs -Q 28.2 peg a core infinitely >> From: Chris Hecker >> Date: Sat, 5 Nov 2022 01:21:34 -0700 >> Cc: 59038@debbugs.gnu.org, Eli Zaretskii , acm@muc.de >> >> > It's a single 21,728-character line. >> >> Yeah? This isn’t 1970. I have 32gb of ram and a 12 core cpu. It’s a bug. It should either parse the file >> (instantly, it’s 27kb) or it should at least stop after a few ms and tell me it’s lame and needs me to switch >> manually to another mode. I mean, given the 28.2 user experience, there is no opportunity to switch to >> fundamental mode because emacs was hosed. I don’t even think ctrl-g worked for me. > >Like I said, try Emacs 29, where this should be fixed. > >I mentioned the actual length of the line FTR, not as an excuse for >unbearably slow display.