bug#55412: 28.1; In Emacs 28.1, using ':eval' in 'frame-title-format' doesn't work properly

[martin rudalics]

> It would be good to have some of these explanations in comments there.

I understand that we want a quick solution for the present bug so it can
be included in Emacs 28.2.  But I still don't understand why nobody even
cared to try the patch I sent earlier.  With the current code, whenever
there are at least two frames present, 'gui_consider_frame_title' calls
via Fselect_window among others

redisplay_other_windows

Fredirect_frame_focus

resize_mini_window

move_minibuffers_onto_frame

and sets

last_nonminibuf_frame

internal_last_event_frame

Has anyone ever tried to understand the implications of all these?  Why
should redisplay indiscriminately set 'windows_or_buffers_changed' when
recomputing the frame title?  Why should we try to redirect frame focus
which is already sufficiently hairy by itself so hardly anyone really
understands what it does.  Why should formatting the frame title try to
resize a mini window or move minibuffers onto the selected frame?

Why set last_nonminibuf_frame which might affect 'display-buffer' and
apparently relies on some internal kludgery to set it precisely to the
same value it had before title line formatting started.  And why reset
internal_last_event_frame which also appears complicated enough to not
touch it unless you know precisely why and when.

Similar things happen with mode lines display - unwind_format_mode_line
apparently can call Fselect_window up to three times in a row with the
implications sketched above.

When trying to fix Bug#32777 I spent some time investigating these
issues but never found out why on earth we should call routines like
'select-frame' and 'select-window' from redisplay.  If there is any
rationale for these, it should be explained in comments first before
moving on to explain why moving minibuffers between frames can go awry.

martin