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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 21 May 2022 10:32:51 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>, 55412@debbugs.gnu.org, tanzer@swing.co.at
> From: martin rudalics <rudalics@gmx.at>
> 
>  > I get nervous when I see "selected_frame = ...;" or "selected_window =
>  > ....;" outside of do_switch_frame or the corresponding window function,
>  > since it means selected_{frame,window} have been set without regard to
>  > all the other things which must be kept in synch with them.  At the
>  > moment, all these "wild" settings of selected_frame are in xdisp.c,
>  > which I suppose has special reasons for them.
> 
> What concerns me is that xdisp.c sets selected_window and selected_frame
> in the first place (also due to my attempts to fix Bug#39977).  My patch
> removes them all.

Frankly, I don't understand why would we want that.  AFAICT, that
patch just moves those assignments to a single place, and what does
that gain us, as counter-weight to potential breakage due to subtly
different stuff the original code was doing?  The new code also makes
the temporary change in the selected window more heavy and expensive,
which is not a good idea inside redisplay.

Note that redisplay also changes the current buffer, and it does that
independently of selecting a window.  I'm not sure window.c is ready
(or was designed) for such subtleties.

> Moreover, the code has to guarantee that selecting a window correctly
> sets up point from the window's point and stores the old point in the
> previously selected window#s point.  And it obviously has to guarantee
> that the involved buffers, windows and frames are alive when switching
> to and back from them - things redisplay had always problems with
> (confer Bug#47244).  Not reliably doing all these things in one place
> easily produces bugs that show up only in sessions that run for a long
> time and are consequently very difficult to debug.

The general advantage of doing things in one place is well known, but
I'm not sure this particular case lends itself well to such
generalizations.  IMNSHO, we are once again rocking a boat for no good
reason (and no, the problems in bug#47244 do _not_ IMO justify this,
because that bug can be fixed in other ways, as mentioned in that and
related discussions several times).

Bottom line, I'm not happy about this patch, sorry.