all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Joseph Mingrone <jrm@ftfl.ca>
To: Stefan Kangas <stefan@marxist.se>
Cc: 32523@debbugs.gnu.org
Subject: bug#32523: 27.0.50; Emacs hangs when killing rectangle
Date: Mon, 24 Aug 2020 15:44:59 -0300	[thread overview]
Message-ID: <86a6yjj32s.fsf@phe.ftfl.ca> (raw)
In-Reply-To: <CADwFkmkYTPUQjcJrWuS_DBHJxv0PN4Q29mAyPqQRaPh-MPidtw@mail.gmail.com> (Stefan Kangas's message of "Fri, 21 Aug 2020 07:06:29 -0700")

On Fri, 2020-08-21 at 07:06, Stefan Kangas <stefan@marxist.se> wrote:

> 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

Hello Stefan,

I just tested the recipe in GNU Emacs 28.0.50 (build 1,
amd64-portbld-freebsd12.1, GTK+ Version 3.24.20, cairo version 1.16.0)
and it's still an issue in that Emacs is difficult to use after
performing the rectangle kill.  However, after the operation completes
*and I kill the buffer visiting the large file*, Emacs become responsive
again.  It's been a long time, but I recall that this wasn't the case in
the past.  I recall having to kill and restart Emacs before it became
usable again.

Joe





      parent reply	other threads:[~2020-08-24 18:44 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-25  0:59 bug#32523: 27.0.50; Emacs hangs when killing rectangle Joseph Mingrone
2018-08-25  8:11 ` Eli Zaretskii
2018-08-25 11:40   ` Joseph Mingrone
2020-08-21 11:51     ` Stefan Kangas
2020-08-21 13:42       ` Eli Zaretskii
2020-08-21 14:06         ` Stefan Kangas
2020-08-21 14:28           ` Eli Zaretskii
2020-08-24 18:44           ` Joseph Mingrone [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86a6yjj32s.fsf@phe.ftfl.ca \
    --to=jrm@ftfl.ca \
    --cc=32523@debbugs.gnu.org \
    --cc=stefan@marxist.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.