Re: Deferring native compilation finalization until idle

On Sat, Jul 25, 2026 at 11:39 AM Perry Fraser <[email protected]> wrote:

> Stéphane Marks <[email protected]> writes:
>
> I pretty much live in Emacs on macOS and this is a non-issue, IME.
>
> Are you able to reproduce the behavior I described when starting with
> an empty config and a custom eln cache path in your early-init.el?
> (I found it especially obvious when launching M-x gnus, hitting m
> to compose a message, and then typing.)
>
> I also assume you aren’t doing anything odd like running with SIP
> disabled.
>

SIP remains enabled on my systems.  On my M1 MAX macOS 26.4 laptop, the
only computer I have access to this month, after installing a jimeh nightly
as I mentioned and using a custom eln cache path (as I always do), it
rebuilds from scratch because the binary hash changed (you can see this in
the variable comp-abi-hash) and I do not see annoying hangs.

What Eli said correctly describes macOS behavior and how to deal
> with it. If you use an Emacs build that follows the “rules” and is
> installed as a bundle as
> https://github.com/jimeh/emacs-builds/releases do, you should not
> see any “hangs.” A couple of days ago, I installed a new nightly
> jimeh bundle which includes prebuilt native modules and recompiled
> all external modules asynchronously just fine and with no delays.
> Restarts are nearly instantaneous. If you are not running from a
> bundle that macOS can “bless,” then you may experience delays.
>
> When launching a bundle downloaded from there by double-clicking the
> .app I still experience the same behavior when my eln cache is empty,
> as well as on my first launch without any eln cache shenanigans.
>
> You did not elaborate on how you start your Emacs sessions. You may
> want to run the bundle from nextstep/Emacs.app rather than running
> the binary directly to benefit from the bundle.
>
> Good point—I normally launch Emacs via either open -n /path/to/Emacs.app,
> though the tests I was doing was by launching the
> installed emacs binary. I can reproduce the issue with both of those
> methods, as well as with just double-clicking the .app in Finder as
> mentioned above.
>

The Emacs main event loop is not impacted by asynchronous native
compilations so I can't say what is preventing your Emacs from processing
input keys.  The only explanation I have is that macOS itself is doing
precisely the thing that etc/PROBLEMS suggests a workaround for and which
the jimeh builds use:

  codesign --force --sign - \
      --entitlements macos-disable-library-validation.entitlements \
      src/emacs

Are you using that?