all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 55412@debbugs.gnu.org, tanzer@swing.co.at
Subject: 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	[thread overview]
Message-ID: <YoDMdTtTv80DjRH5@ACM> (raw)
In-Reply-To: <838rr4kq56.fsf@gnu.org>

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





  parent reply	other threads:[~2022-05-15  9:48 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-14 15:45 bug#55412: 28.1; In Emacs 28.1, using ':eval' in 'frame-title-format' doesn't work properly Christian Tanzer
2022-05-14 16:58 ` Eli Zaretskii
2022-05-14 17:07   ` Eli Zaretskii
2022-05-15  9:48   ` Alan Mackenzie [this message]
2022-05-15 10:16     ` Eli Zaretskii
2022-05-16 20:52   ` Alan Mackenzie
2022-05-17 13:25     ` Eli Zaretskii
2022-05-18  7:19     ` martin rudalics
2022-05-18 11:35       ` Eli Zaretskii
2022-05-18 15:01         ` martin rudalics
2022-05-18 15:12           ` Alan Mackenzie
2022-05-18 15:49           ` Alan Mackenzie
2022-05-18 16:03             ` Eli Zaretskii
2022-05-18 16:38               ` Alan Mackenzie
2022-05-18 16:51                 ` Eli Zaretskii
2022-05-20  8:23                   ` martin rudalics
2022-05-20 10:58                     ` Eli Zaretskii
2022-05-21  8:32                       ` martin rudalics
2022-05-21  8:35                         ` Eli Zaretskii
2022-05-20 11:33                     ` Alan Mackenzie
2022-05-20 12:10                       ` Eli Zaretskii
2022-05-21  8:32                       ` martin rudalics
2022-05-21  8:59                         ` Eli Zaretskii
2022-05-19  7:18             ` martin rudalics
2022-05-20 20:39   ` Alan Mackenzie
2022-05-21 11:25     ` tanzer--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-05-21 12:35       ` Eli Zaretskii
2022-05-22 17:34       ` Alan Mackenzie
2022-05-15  9:28 ` martin rudalics

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YoDMdTtTv80DjRH5@ACM \
    --to=acm@muc.de \
    --cc=55412@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=tanzer@swing.co.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.