[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#32523: 27.0.50; Emacs hangs when killing rectangle
From: |
Stefan Kangas |
Subject: |
bug#32523: 27.0.50; Emacs hangs when killing rectangle |
Date: |
Fri, 21 Aug 2020 07:06:29 -0700 |
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