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

[Chris Hecker <checker@d6.com>]

[-- Attachment #1: Type: text/plain, Size: 1605 bytes --]

>> (instantly, it’s 27kb)
> Which is a lot, even in this day and age.

I don't even know what to say to this.  Literally every other editor I
tried including the immense pile that is visual studio opened this file
instantly, including ones that do syntax highlighting.

I love emacs but holy cow you need to renormalize what you think a modern
computer is capable of so your performance expectations for emacs are more
realistic.

Anyway, I’m glad it’s fixed in 29.

Chris

On Sat, Nov 5, 2022 at 04:29 Po Lu <luangruo@yahoo.com> wrote:

> Chris Hecker <checker@d6.com> writes:
>
> > Yeah?  This isn’t 1970.
>
> Emacs becoming unusable due to long lines has been fixed in Emacs 29.
>
> > I have 32gb of ram and a 12 core cpu.
>
> Physical memory and the number of processors installed does not really
> matter here, unfortunately, as Emacs only uses one processor to process
> your (27kb) file.
>
> > (instantly, it’s 27kb)
>
> Which is a lot, even in this day and age.
>
> > 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.
>
> A few ms is shorter than a roundtrip to and fro the X server over my
> current connection.  But:
>
> > 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.
>
> All of this is no longer a problem in Emacs 29, and even if you somehow
> still cause redisplay to become wedged, you can set max-redisplay-ticks
> to a suitable value.
>

[-- Attachment #2: Type: text/html, Size: 2309 bytes --]