bug#59038: Re[2]: bug#59038: loading this base64 file makes emacs -Q 28.2 peg a core infinitely

[Chris Hecker]

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" <eliz@gnu.org>

To: "Chris Hecker" <checker@d6.com>

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 <checker@d6.com>

Date: Sat, 5 Nov 2022 01:21:34 -0700

Cc: 59038@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>, 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.