Why doesn't emacs yield more?

Why doesn't emacs yield more?

[ndame]

I inadvertently pasted a huge elisp list structure into a buffer
and it took me 10 seconds or so to regain control, because emacs
was bogged down by formatting/highlighting the list I think.

It tried to hit C-g several times to no avail which made me
think: why doesn't emacs yield more during long operations by
checking if the user canceled the operation?

I don't mean putting checks everywhere manually, but using some
automatic code translator which would inject such checks
automatically in the source codes of loops or something, before
the actual compilation of emacs.

Would it be a big performance hit? I don't know if the check
could be inlined somehow. Was something like this discussed
before?


(I posted this to help, because I don't know the internal architecture
of emacs, so the question may be naive or unworkable.)

Re: Why doesn't emacs yield more?

[Eli Zaretskii]

> From: ndame <emacsuser@freemail.hu>
> Date: Thu, 29 Aug 2019 11:33:42 +0200 (CEST)
> 
> I inadvertently pasted a huge elisp list structure into a buffer
> and it took me 10 seconds or so to regain control, because emacs
> was bogged down by formatting/highlighting the list I think.

I'm guessing most of the time was taken by redisplay.  Unless by
"pasting" you mean something other than just C-y.  I'd suggest to tell
more details about the Lisp list structure in question and what you
did to paste it.  Otherwise, this discussion runs a risk of lacking a
solid basis, and could easily be talking about things irrelevant to
your use case.

> It tried to hit C-g several times to no avail which made me
> think: why doesn't emacs yield more during long operations by
> checking if the user canceled the operation?

Emacs does check for C-g during prolonged operations, but only when it
runs Lisp code.  I don't think that's what took most of the time in
your case.

Assuming it was redisplay that took most of the time: you cannot
interrupt it, not by default.  What would be the purpose of that?
Emacs cannot allow the display to be left in a state that is
inconsistent with the contents of the buffer, so it will immediately
reenter another redisplay cycle.

What you can do is type M-< to go to the beginning of the buffer.  If
the problematic portion of the buffer will then be off-screen, you
should be able to stop waiting.

You could also set redisplay-dont-pause non-nil, but IME it helps only
in a small fraction of use cases, and otherwise its effect is for the
worse.

> I don't mean putting checks everywhere manually, but using some
> automatic code translator which would inject such checks
> automatically in the source codes of loops or something, before
> the actual compilation of emacs.
> 
> Would it be a big performance hit? I don't know if the check
> could be inlined somehow. Was something like this discussed
> before?

We already do all that when running Lisp code.

Re: Why doesn't emacs yield more?

[Stefan Monnier]

> I inadvertently pasted a huge elisp list structure into a buffer
> and it took me 10 seconds or so to regain control, because emacs
> was bogged down by formatting/highlighting the list I think.

Pasting doesn't format, normally.  As for highlighting...:
- If the structure is all on a single line, then the problem is likely
  just the usual (set of) "long lines" problem.
- If it's spread over many lines, then only a handful of lines (those
  that are visible) should be highlighted, so that shouldn't be it.

IOW, please M-x report-emacs-bug so we can try and figure out what went wrong,


        Stefan

Re: Why doesn't emacs yield more?

[ndame]

> 
> Assuming it was redisplay that took most of the time: you cannot
> interrupt it, not by default.  What would be the purpose of that?
> Emacs cannot allow the display to be left in a state that is
> inconsistent with the contents of the buffer, so it will immediately
> reenter another redisplay cycle.

If I e.g. do a C-y and consquently emacs starts a long operation then
if I interrupt then emacs could simply restore the buffer/display state
from before the C-y state. I didn't see my C-y operation finish
because of the redisplay, so I wouldn't mind if a C-g would cancel that
too.

I don't know if a snapshot can be made of the current buffer/display
state, but if emacs can do that then it could simply restore the
previous snapshot instantly, so there would be no issue of inconsistent
buffer/display after interrupting.


> What you can do is type M-< to go to the beginning of the buffer.  If
> the problematic portion of the buffer will then be off-screen, you
> should be able to stop waiting.

Interesting. I'll try it next time.

> > 
> > Would it be a big performance hit? I don't know if the check
> > could be inlined somehow. Was something like this discussed
> > before?
> 
> We already do all that when running Lisp code.

Thanks. I didn't know that.

Re: Why doesn't emacs yield more?

[Eli Zaretskii]

> From: ndame <emacsuser@freemail.hu>
> Date: Thu, 29 Aug 2019 17:39:20 +0200 (CEST)
> 
> > Assuming it was redisplay that took most of the time: you cannot
> > interrupt it, not by default.  What would be the purpose of that?
> > Emacs cannot allow the display to be left in a state that is
> > inconsistent with the contents of the buffer, so it will immediately
> > reenter another redisplay cycle.
> 
> If I e.g. do a C-y and consquently emacs starts a long operation then
> if I interrupt then emacs could simply restore the buffer/display state
> from before the C-y state.

Emacs doesn't support transactional operations, not in general.  Once
you yank some text, the global state could be modified to the degree
that rolling it back may not be possible; and Emacs doesn't know how
anyway.

> I didn't see my C-y operation finish because of the redisplay, so I
> wouldn't mind if a C-g would cancel that too.

Most use cases are different.  What if, e.g., the command that hangs
sends some material over a network connection, or writes it to a file,
or passes it to a subprocess?

You can always undo manually, of course, and that could be one more
way of stopping a prolonged redisplay (assuming this is what caused
the delay in your case; you still haven't described enough detail for
me to know what are we talking about).

> I don't know if a snapshot can be made of the current buffer/display
> state, but if emacs can do that then it could simply restore the
> previous snapshot instantly, so there would be no issue of inconsistent
> buffer/display after interrupting.

That's a far cry from how Emacs was designed and implemented.  It
isn't a transactional system.