Delay in after-focus-change-function

[fast-90]

I am using pulsar and am trying to make the package "pulse" (i.e. briefly highlight) the current line once my emacs frame gains focus (e.g. if I switch from my browser to my emacs frame). This works ok, however there is a slight delay before it pulses. See also attached video. On my other computer where I am running WSL, the line pulses instantly when I switch to my emacs frame.

I have also tried to replicate the issue with emacs -Q with the following lines in my config:

(defun hello ()
  (message "Hello"))

(add-function :after after-focus-change-function (lambda () (if (frame-focus-state) (hello))))

This gives me the same issue as well, i.e. it takes a while before the echo area shows "Hello" after switching focus to my emacs frame.

Considering it is not happening on my WSL computer and also not happening for Prot (who helped me test it on his side), I am assuming this is specific to my emacs installation. Does anyone have an idea why I have this delay, and any potential solutions to remove or at least decrease the delay?

I am running the following version btw:
GNU Emacs 29.0.50 (build 1, x86_64-apple-darwin21.5.0, NS appkit-2113.50 Version 12.4 (Build 21F79)) of 2022-07-10

Screen.Recording.2022-08-18.at.07.20.11.mov

[d12frosted]

Hey, sorry for a long reply. Please share the command you used to install Emacs. Also, I would suggest to try with https://emacsformacosx.com. And if the probelm persists there, I would suggest to report it to mailing list.

This repository is responsible only for the formula for homebrew. I am not Emacs developer 😸 And I know little about Emacs internals/code base.

WSL

Don't know what's that.

also not happening for Prot

I am pretty sure he is not using macOS. This issue might be related to Emacs in macOS. There is a reason behind emacs-mac by Mitsuharu Yamamoto, which is kind of macOS friendly fork of GNU Emacs.

[glyph]

I've noticed a similar delay. If I press a key or do anything else, it seems like it gets processed instantly, which suggests that there is a bug here where the event loop is not processing the focus-in event until it has read another event from the queue, or times out doing so.

It doesn't have to be a keyboard event. For example, if I'm moving my mouse in circles over the window when I tab into it, the UI responds instantly. It's only if I command-tab in and do nothing else — no mouse movements, no keyboard movements.