Re: Zoom: a window management minor mode -- best practices and questions

[Andrea Cardaci <cyrus.and@gmail.com>]

> I don't remember (perhaps Martin does).  But if you show a C-level
> backtrace from such a call to buffer-list-update-hook, it will be easy
> to say whether this is expected or not.

Is there a simple way to dump a backtrace from Emacs?

It's easy to reproduce tough:

(defun foo ()
  (message "buffer-list-update-hook"))

(add-hook 'buffer-list-update-hook 'foo)

then simply click in the selected window.

Anyway according to the documentation this hook is called by
`select-window` which is actually called if you click on a window,
even if it is the selected one.

> Do you mean that pre-redisplay-function is called?  If not, what
> exactly do you mean by "relayout is triggered"?

Yeah, I mean I collect all the events which tell me that a relayout is
needed (window created/destroyed, window/buffer selected, etc.) then
finally I perform the actual relayout. If a subsequent event tells me
that a relayout is needed but no window has been actually
created/destroyed etc. then it's a false positive, in this case for
example it happens when `pre-redisplay-function` is called, e.g., when
the user clicks in the selected window.

(By relayout I mean what Zoom does: `balance-windows` and resize the
selected window.)

> That's strange.  The most frequent call to pre-redisplay-function is
> in prepare_menu_bars; are you saying that function is never called on
> macOS?

Well, there's more than that, it doesn't seem to be a macOS thing. If I do:

(defun foo (x)
  (message "pre-redisplay-function"))

(add-hook 'pre-redisplay-function 'foo)

Almost always, the hook is not called when I interact with windows and
the text selection mark becomes invisible for future selections (!),
even in the terminal. Otherwise (but I cannot reproduce it anymore...)
the hook is called very frequently, even when Emacs is idle.

Emacs 26.0.90 on Linux, using the -Q option.

> If you put a breakpoint inside that function, does it never break?

`prepare_menu_bars` does break but `FUNCTIONP
(Vpre_redisplay_function)` is false so `safe__call1 (true,
Vpre_redisplay_function, windows);` is never executed.