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

Message #17 received at 55412 <at> debbugs.gnu.org (full text, mbox):

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
Subject: Re: bug#55412: 28.1; In Emacs 28.1, using ':eval' in
 'frame-title-format' doesn't work properly
Date: Sun, 15 May 2022 09:48:37 +0000

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'

> > (defun title-suffix ()
> >   (cdr (assoc 'title-suffix (frame-parameters (selected-frame)))))

> > (defvar title-prefix "Test")
> > (setq frame-title-format (list title-prefix '(:eval (title-suffix)) " %b"))

> > ;;; The original frame should show a frame title of 'Test *scratch*'
> > (set-frame-parameter (selected-frame) 'title-suffix "")

> > ;;; The next frame created should show a frame title of 'Test-xxx *scratch*'
> > (make-frame-command)
> > (set-frame-parameter (selected-frame) 'title-suffix "-xxx")

> > ;;; The third frame created should show a frame title of 'Test-yyy *scratch*'
> > (make-frame-command)
> > (set-frame-parameter (selected-frame) 'title-suffix "-yyy")

> > ;;; 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.

> 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 remember vaguely that that call to Fselect_window caused minibuffers to
be switched between frames in an unwanted fashion.  I've got detailed
notes of what I did, still.  I'll probably not have much chance to look
at the bug today, but should do over the next few days.

> 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.