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

[martin rudalics <rudalics@gmx.at>]

 > 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