bug#34765: 26.1; with-temp-buffer should not run buffer-list-update-hook

[martin rudalics]

> To quote from the documentation of select-window:
>
> Selections that "really count" are those
> causing a visible change in the next redisplay of WINDOW’s frame and
> should be always recorded. So if you think of running a function each
> time a window gets selected put it on ‘buffer-list-update-hook’.
>
> A temporary buffer hardly fits these criteria.

You're probably right but there's not much we can do in this regard.
When you show a temporary buffer and temporarily show another buffer
in the same window, there must be a way to show the temporary buffer
again.  That's why we have to run 'buffer-list-update-hook' for them.

> The problem is not just
> theoretical either. I have now run multiple times into situations where
> use of a temp buffer caused a feedback loop that makes
> buffer-list-update-hook fire permanently. For example a function called
> by buffer-list-update-hook uses with-selected-window, this causes a
> recalculation of the frame title, that calls format-spec, which uses a
> temp-buffer and we are back to step one. Granted this case is very
> specific to spacemacs and I am unable to reproduce it from emacs -q
> (with-selected-window does not recalculate the frame title here), but
> this is already the second time I've run into this

'with-selected-window' calls 'select-window' with NORECORD non-nil, so
this should not be the culprit.  I'm afraid you have to dig further to
find out how 'buffer-list-update-hook' precisely gets called here.

> (first time it was
> magit).

What was the issue there?

> So yeah, with-temp-buffer correction aside, if you have any advice how
> to avoid the issue on my end without going back to advising
> select-window that'd be great.

Emacs 27 now has 'window-selection-change-functions', strongly tied to
redisplay and triggering only when the window selection has changed
since last redisplay.  Maybe you could try that.

martin