bug#32729: Xemacs 23 times as fast as GNU Emacs

[Lars Ingebrigtsen]

Phil Sainty <psainty@orcon.net.nz> writes:

> On 12/10/19 4:57 PM, Lars Ingebrigtsen wrote:
>> (Note: Don't visit the " *zeroes*" buffer after this, because that
>> will hang Emacs totally.  I guess the long-line display problem
>> hasn't been fixed after all?)
>
> I imagine you're thinking of so-long.el here, in which case there may
> be a misconception.

Yes, I hadn't followed the development closely, but just registered that
... things ... had gotten better.  :-)

> The biggest problem in this case (by far) is that point has been left
> at the end of the line following the insertion, and in order for the
> redisplay to *display* the end of the line, it's having to process a
> gigabyte of data.  My largest test case for so-long.el was a couple of
> orders of magnitude smaller than this, and Emacs wasn't remotely happy
> showing the end of that line, let alone this one.

Ah, I see.  Thanks for the explanation.

It is unfortunate that stuff like this makes Emacs hang, though.  It'd
be nice if Emacs had a "OK, we just give up" mode if the buffer is too
intractable, where "too intractable" may be, for instance, if it finds a
line that's longer than a few megabytes, perhaps?

I don't know what "just give up" would entail, though.  Just put point
at the start of the buffer and refuse to scroll or do anything?  Just
about anything would be better than the current situation where you have
to kill Emacs if you're playing with (some) binary files and try to
display the buffer.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no