bug#32523: 27.0.50; Emacs hangs when killing rectangle

[Stefan Kangas <stefan@marxist.se>]

Eli Zaretskii <eliz@gnu.org> writes:

>> > The rectangle does eventually get cut for me as well.  Ignoring speed,
>> > the problem is that Emacs is unusable afterwards.  For example, if I go
>> > away for an hour or so, then return, the Emacs process will still be
>> > using something close to 100% CPU and trying to doing something simple,
>> > like moving the point forward, may take minutes.
>>
>> Are you still seeing this behaviour?
>
> I bet he does.  the problem with the slow responses after cutting the
> rectangle is that Emacs performs redisplay each type the user types
> some character.  The redisplay can be very small and optimized, but it
> can also be much more thorough; for example, typing "M-x" typically
> triggers a thorough redisplay.  Each time we need to perform a
> non-trivial redisplay, the same problem with long lines hits again.

Ah, so you interpret what he writes to mean that he leaves Emacs _in the
same buffer_ and then sees these results?  Yes, that makes sense.  I
somehow assumed he meant that this was persistent even after closing the
problematic buffer, but he didn't say that explicitly.

Asking the same questions here as in another bug report:

Is there anything more we can/should do in this case short of rewriting
the display engine?  Does it make sense to track this limitation in a
bug report?

etc/PROBLEMS says:

*** Editing files with very long lines is slow.

For example, simply moving through a file that contains hundreds of
thousands of characters per line is slow, and consumes a lot of CPU.
This is a known limitation of Emacs with no solution at this time.

Best regards,
Stefan Kangas