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

Previous Next

Full log

View this message in rfc822 format

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 55412 <at> debbugs.gnu.org, tanzer <at> swing.co.at, acm <at> muc.de
Subject: bug#55412: 28.1; In Emacs 28.1, using ':eval' in 'frame-title-format' doesn't work properly
Date: Mon, 16 May 2022 20:52:42 +0000

Hello, Eli.

On Sat, May 14, 2022 at 19:58:13 +0300, Eli Zaretskii wrote:
> > Date: Sat, 14 May 2022 15:45:10 -0000
> > From: Christian Tanzer <tanzer <at> swing.co.at>

> > ;;; In Emacs 28.1, using ':eval' in 'frame-title-format' doesn't work like it
> > ;;; used to in Emacs 27 and earlier. In fact, it is completely broken, if one
> > ;;; uses a frame-parameter in ':eval'.
> > ;;;
> > ;;; The following elisp snippet demonstrates the problem in an Emacs 28.1
> > ;;; instance started with 'emacs -Q'

[ .... ]

> > ;;; In Emacs 27 and earlier, that is exactly what happens. Selecting a
> > ;;; different frame doesn't change the titles of all other frames.

> > ;;; In Emacs 28.1, all frames show the same frame title, with the last one
> > ;;; selected determining which one is shown for the bunch of them. Changing to
> > ;;; a different frame changes the titles of all frames to the title of the
> > ;;; newly selected one.

> Thank you for your report.

> Alan, this is due to one of the changes introduced for the
> minibuffer-follows-selected-frame feature.  Specifically, commit
> 7c2ebf6 made a change in gui_consider_frame_title which causes this
> regression.  If I revert a part of that commit as shown below:

> diff --git a/src/xdisp.c b/src/xdisp.c
> index 6963935..9740e6b 100644
> --- a/src/xdisp.c
> +++ b/src/xdisp.c
> @@ -12796,8 +12796,9 @@ gui_consider_frame_title (Lisp_Object frame)
>  	 mode_line_noprop_buf; then display the title.  */
>        record_unwind_protect (unwind_format_mode_line,
>  			     format_mode_line_unwind_data
> -			     (NULL, current_buffer, Qnil, false));
> +			     (f, current_buffer, selected_window, false));
 
> +      Fselect_window (f->selected_window, Qt);
>        set_buffer_internal_1
>  	(XBUFFER (XWINDOW (f->selected_window)->contents));
>        fmt = FRAME_ICONIFIED_P (f) ? Vicon_title_format : Vframe_title_format;

> then the problem goes away.

Yes.  It is clear that that Fselect_window call is needed.

> The log message of that commit says about this part:

>     * src/xdisp.c (gui_consider_frame_title): Remove redundant Fselect_window,
>     which caused an unwanted frame switch.  Amend the arguments to
>     format_mode_line_unwind_data to match.

> As you see, the call to select-window is not redundant, because
> without it the frame's title cannot reference the frame-parameters of
> that frame.

> Do you remember why the frame switch here was "unwanted"?  What
> bad things happen if we restore the removed code?

I think I've managed to reconstruct why I made this part of the change.
With the Fselect_window call in place:
(i) When minibuffer-follows-selected-frame is nil, and the minibuffer is
  the current window before switching frames with C-x 5 o, it remains the
  current window on returning to the first frame.
(ii) When minibuffer-follows-selected-frame is t (the default) and other
  circumstances are as in (i), the minibuffer is no longer the selected
  window on returning to the first frame.
I wanted to fix this inconsistency, I think.

Clearly, this inconsistency is less important than frame-title-format not
working.  May I suggest that one of us applies your patch immediately to
the release branch.  I will then attempt to find a less harmful way of
fixing that inconsistency, and will take direction from you which branch
it should be committed to.

> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.