bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#55412: 28.1; In Emacs 28.1, using ':eval' in 'frame-title-format' do


From: Eli Zaretskii
Subject: bug#55412: 28.1; In Emacs 28.1, using ':eval' in 'frame-title-format' doesn't work properly
Date: Sat, 14 May 2022 19:58:13 +0300

> Date: Sat, 14 May 2022 15:45:10 -0000
> From: Christian Tanzer <tanzer@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 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?

Thanks.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]