masm11/emacs

Minibuffer feels frozen when using straight.el's `straight-rebuild-all`

Closed this issue · 15 comments

See screencast https://streamable.com/f7ttx8

In the screen cast, left is Emacs 27.2 running on xwayland and right is
PGTK Emacs running on wayland. Both has a lot messages been output to minibuffer.
The left behaves fluent while the PGTK feels frozen.

straight.el is an Emacs functional package manager.
https://github.com/raxod502/straight.el.

Just compiled emacs-mirror@5b97b98 without --with-pgtk, minibuffer behaviors the same as 27.2. Pretty sure it's a pgtk issue.

Write to cairo_surface_t some times, and copy the result to window.
It is gtk-way.

In this issue:
at "Write to cairo_surface_t some times", all the message buffer changes go to cairo_surface_t, and after that
at "copy the result to window", the cairo_surface_t goes to the window.
Because straight.el is very busy while rebuilding.

I'll look for a workaround.

I had been stepping through the redisplay code in the little time I get to work on emacs now, I noticed that I missed the change in 9ae94eb where the gui_update_window_begin|end functions were added and the platform specific ones were removed.
This meant we executed that code twice as it the pgtk specific work was identical.

It seems to have made some difference as straight-rebuild-all now appears to update the minibuffer.

@masm11, the attached patch should apply to the feature/pgtk branch on savannah.

0001-src-pgtkterm.c-remove-duplicated-code.patch.txt

Just tested the patch. It's still the same though.

Also forget to mention that C-g is not working when executing
straight-rebuild-all while it immediately stops when using 27.2

@declanqian my machine locked you and I thought this comment did not actually get posted.

I had a dirty build environment and wasn't actually building emacs as expected.

The patch is still a good idea. But does not address this particular problem.

@fejfighter Thanks. Committed and pushed.

This is a weird bug.

If I put (straight-rebuild-all) in the scratch buffer and call C-j or C-x C-e it will update the minibuffer. but if I call the same function through M-x it will not update

Seemingly it's an issue with high load interactive function calls

and I confirmed that I had a clean, correctly compiled 'pgtk-emacs

(let ((i 0))
  (while (< i 100000)
    (message "i %i" i)
    (setq i (1+ i))
    (sit-for 1)))

This code counts up, but it stops counting up after pressing any key.
That may be related.

If I define:

(global-set-key "\C-w" 'straight-rebuild-all)

and use it, start_hourglass is called.
While straight-rebuild-all is executing, atimer event is called
periodically. When that, drawing is processed.

If I execute it with M-x straight-rebuild-all,
start_hourglass is called but cancel_hourglass is also called.
So atimer event is not called.

test2.log

Using a smaller, modified version of the counting snippet above I get a minimal log as attached, at some pint (around 3) i hit a key and the PGTK_TRACE log is much shorter for each message call

I tried to fix in 8a649cb.
It fixed this issue but generated frame-positioning issue, so I reverted it.

@declanqian
Could you build emacs-mirror@master and confirm whether the issue reproduces yet?

Nice, the issue does not reproduce any more.
Can you kindly point out the commit which fixed this issue? @masm11
Also, I think this issue can be closed now.

@declanqian Thanks for the confirmation.

Can you kindly point out the commit which fixed this issue?

I'm not sure, but maybe b327788 by Po Lu.

I'm not sure, but maybe b327788 by Po Lu.

Thanks for adding this link.