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 ------
Sent: 2022-11-05 02:30:58
Subject: Re: bug#59038: loading this base64 file makes emacs -Q 28.2 peg a core infinitely
Date: Sat, 5 Nov 2022 01:21:34 -0700
> 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.