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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 55412 in the body.
You can then email your comments to 55412 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Christian Tanzer <tanzer <at> swing.co.at>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.1; In Emacs 28.1, using ':eval' in 'frame-title-format' doesn't
 work properly
Date: Sat, 14 May 2022 15:45:10 -0000

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


In GNU Emacs 28.1 (build 1, aarch64-apple-darwin21.1.0, NS appkit-2113.00 Version 12.0.1 (Build 21A559))
 of 2022-04-04 built on armbob.lan
Windowing system distributor 'Apple', version 10.3.2113
System Description:  macOS 12.3.1

Configured using:
 'configure --with-ns '--enable-locallisppath=/Library/Application
 Support/Emacs/${version}/site-lisp:/Library/Application
 Support/Emacs/site-lisp' --with-modules'

Configured features:
ACL GMP GNUTLS JSON LIBXML2 MODULES NOTIFY KQUEUE NS PDUMPER THREADS
TOOLKIT_SCROLL_BARS ZLIB

Important settings:
  value of $EMACSLOADPATH: /Users/tanzer/.emacs.lib::/Applications/Emacs.app/Contents/Resources/site-lisp:
  value of $LC_CTYPE: UTF-8
  value of $LC_MESSAGES: en_US.UTF-8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
/Users/tanzer/.emacs.lib/custom hides /Applications/Emacs-28.1.app/Contents/Resources/lisp/custom
/Users/tanzer/.emacs.lib/iso-transl hides /Applications/Emacs-28.1.app/Contents/Resources/lisp/international/iso-transl

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search time-date
subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel term/ns-win ns-win ucs-normalize
mule-util term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads kqueue cocoa ns multi-tty
make-network-process emacs)

Memory information:
((conses 16 51129 6052)
 (symbols 48 6554 1)
 (strings 32 18387 2569)
 (string-bytes 1 613674)
 (vectors 16 14168)
 (vector-slots 8 205987 11758)
 (floats 8 33 51)
 (intervals 56 234 0)
 (buffers 992 10))

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: tanzer <at> swing.co.at, Alan Mackenzie <acm <at> muc.de>
Cc: 55412 <at> debbugs.gnu.org
Subject: Re: 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 <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 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.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: acm <at> muc.de
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: Sat, 14 May 2022 20:07:48 +0300

> Cc: 55412 <at> debbugs.gnu.org
> Date: Sat, 14 May 2022 19:58:13 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> If I revert a part of that commit shown below:

Sorry for confusing wording.  I meant to say

  If I revert a part of that commit _as_ shown below:

That is, what was "shown below" was the _reverse_ of what commit
7c2ebf6 did.

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

From: martin rudalics <rudalics <at> gmx.at>
To: tanzer <at> swing.co.at, 55412 <at> debbugs.gnu.org
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 11:28:16 +0200

[Message part 1 (text/plain, inline)]

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

Could you try the attached patch?  Its purpose is to solve a more
general problem in this area and I had to scrape it out from my sources
so there are most likely dragons around.  But AFAICT it does not exhibit
the problem you see, tested with a GNUstep build on old stable Debian.

Thanks, martin

[with-window-selected.diff (text/x-patch, attachment)]

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
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 13:16:45 +0300

> Date: Sun, 15 May 2022 09:48:37 +0000
> Cc: tanzer <at> swing.co.at, 55412 <at> debbugs.gnu.org
> From: Alan Mackenzie <acm <at> muc.de>
> 
> > 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.

If that is the problem, we could perhaps countermand it by binding
some variable across the call.

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

TIA.

Message #23 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, acm <at> muc.de
Subject: Re: 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).

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

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

> Date: Mon, 16 May 2022 20:52:42 +0000
> Cc: tanzer <at> swing.co.at, 55412 <at> debbugs.gnu.org, acm <at> muc.de
> From: Alan Mackenzie <acm <at> muc.de>
> 
> 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, please go ahead and install the patch on the emacs-28 branch.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Alan Mackenzie <acm <at> muc.de>, 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: Wed, 18 May 2022 09:19:48 +0200

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

When I type M-:, save the expression to evaluate from some other frame,
and the subsequent yank inserts that expression into a normal buffer
instead of the minibuffer, the resulting behavior does not constitute a
less important inconsistency but an annoying regression.  This is one of
the things that used to work "ever since".

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

In that case please default 'minibuffer-follows-selected-frame' to nil
and then try to find a suitable solution.  Or try the patch I posted.

martin

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 55412 <at> debbugs.gnu.org, acm <at> muc.de, 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: Wed, 18 May 2022 14:35:27 +0300

> Date: Wed, 18 May 2022 09:19:48 +0200
> Cc: 55412 <at> debbugs.gnu.org, tanzer <at> swing.co.at
> From: martin rudalics <rudalics <at> gmx.at>
> 
> When I type M-:, save the expression to evaluate from some other frame,
> and the subsequent yank inserts that expression into a normal buffer
> instead of the minibuffer, the resulting behavior does not constitute a
> less important inconsistency but an annoying regression.  This is one of
> the things that used to work "ever since".

Can you tell more about the inconsistency you get in this scenario?
I'm afraid I don't follow the description and therefore cannot try
reproducing it myself.

Thanks.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 55412 <at> debbugs.gnu.org, acm <at> muc.de, 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: Wed, 18 May 2022 17:01:43 +0200

>> When I type M-:, save the expression to evaluate from some other frame,
>> and the subsequent yank inserts that expression into a normal buffer
>> instead of the minibuffer, the resulting behavior does not constitute a
>> less important inconsistency but an annoying regression.  This is one of
>> the things that used to work "ever since".
>
> Can you tell more about the inconsistency you get in this scenario?
> I'm afraid I don't follow the description and therefore cannot try
> reproducing it myself.

Suppose I want to calculate the sum of two numbers: number-1 is shown in
a buffer on frame-1, number-2 is show in a buffer on frame-2.  I start
typing M-: (+ on frame-1 then I do C-x o, mark number-1, type M-w, C-x o
and C-y to yank number-1 into the minibuffer.  Then I add a space to the
minibuffer, type C-x 5 o to go to frame-2, mark number-2, type M-w and
C-x 5 o to get back to frame-1.

Ever since, that last C-x 5 o got me to the minibuffer window.  With the
proposed change, that C-x 5 o will get me to the window of number-1 and
I have to manually select the minibuffer window to yank number-2 there.

martin

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

From: Alan Mackenzie <acm <at> muc.de>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 55412 <at> debbugs.gnu.org, tanzer <at> swing.co.at, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#55412: 28.1; In Emacs 28.1, using ':eval' in
 'frame-title-format' doesn't work properly
Date: Wed, 18 May 2022 15:12:56 +0000

Hello, Martin.

On Wed, May 18, 2022 at 17:01:43 +0200, martin rudalics wrote:
>  >> When I type M-:, save the expression to evaluate from some other frame,
>  >> and the subsequent yank inserts that expression into a normal buffer
>  >> instead of the minibuffer, the resulting behavior does not constitute a
>  >> less important inconsistency but an annoying regression.  This is one of
>  >> the things that used to work "ever since".
>  >
>  > Can you tell more about the inconsistency you get in this scenario?
>  > I'm afraid I don't follow the description and therefore cannot try
>  > reproducing it myself.

> Suppose I want to calculate the sum of two numbers: number-1 is shown in
> a buffer on frame-1, number-2 is show in a buffer on frame-2.  I start
> typing M-: (+ on frame-1 then I do C-x o, mark number-1, type M-w, C-x o
> and C-y to yank number-1 into the minibuffer.  Then I add a space to the
> minibuffer, type C-x 5 o to go to frame-2, mark number-2, type M-w and
> C-x 5 o to get back to frame-1.

> Ever since, that last C-x 5 o got me to the minibuffer window.  With the
> proposed change, that C-x 5 o will get me to the window of number-1 and
> I have to manually select the minibuffer window to yank number-2 there.

I think I can see where the problem is.  I've even found the patch where
this problem was introduced.

I'll see if I can get a patch to you this evening to fix it.

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Alan Mackenzie <acm <at> muc.de>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 55412 <at> debbugs.gnu.org, tanzer <at> swing.co.at, Eli Zaretskii <eliz <at> gnu.org>,
 acm <at> muc.de
Subject: Re: bug#55412: 28.1; In Emacs 28.1, using ':eval' in
 'frame-title-format' doesn't work properly
Date: Wed, 18 May 2022 15:49:36 +0000

Hello, Martin and Eli.

On Wed, May 18, 2022 at 17:01:43 +0200, martin rudalics wrote:
>  >> When I type M-:, save the expression to evaluate from some other frame,
>  >> and the subsequent yank inserts that expression into a normal buffer
>  >> instead of the minibuffer, the resulting behavior does not constitute a
>  >> less important inconsistency but an annoying regression.  This is one of
>  >> the things that used to work "ever since".

>  > Can you tell more about the inconsistency you get in this scenario?
>  > I'm afraid I don't follow the description and therefore cannot try
>  > reproducing it myself.

> Suppose I want to calculate the sum of two numbers: number-1 is shown in
> a buffer on frame-1, number-2 is show in a buffer on frame-2.  I start
> typing M-: (+ on frame-1 then I do C-x o, mark number-1, type M-w, C-x o
> and C-y to yank number-1 into the minibuffer.  Then I add a space to the
> minibuffer, type C-x 5 o to go to frame-2, mark number-2, type M-w and
> C-x 5 o to get back to frame-1.

> Ever since, that last C-x 5 o got me to the minibuffer window.  With the
> proposed change, that C-x 5 o will get me to the window of number-1 and
> I have to manually select the minibuffer window to yank number-2 there.

Please try the following patch, which may solve the above problem
without hurting the bug fix.



diff --git a/src/frame.c b/src/frame.c
index ccac18d23c..7869726850 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -1564,6 +1564,10 @@ do_switch_frame (Lisp_Object frame, int track, int for_deletion, Lisp_Object nor
   if (! FRAME_MINIBUF_ONLY_P (XFRAME (selected_frame)))
     last_nonminibuf_frame = XFRAME (selected_frame);
 
+  if (EQ (f->selected_window, f->minibuffer_window)
+      && NILP (Fminibufferp (XWINDOW (f->minibuffer_window)->contents, Qt)))
+    Fset_frame_selected_window (frame, Fframe_first_window (frame), Qnil);
+
   Fselect_window (f->selected_window, norecord);
 
   /* We want to make sure that the next event generates a frame-switch
diff --git a/src/frame.h b/src/frame.h
index 0b8cdf62de..87c44dd22b 100644
--- a/src/frame.h
+++ b/src/frame.h
@@ -123,7 +123,8 @@ #define EMACS_FRAME_H
   /* This frame's selected window.
      Each frame has its own window hierarchy
      and one of the windows in it is selected within the frame.
-     The selected window of the selected frame is Emacs's selected window.  */
+     The selected window of the selected frame is Emacs's selected window.
+     This window may be the mini-window of the frame.  */
   Lisp_Object selected_window;
 
   /* This frame's selected window when run_window_change_functions was
diff --git a/src/minibuf.c b/src/minibuf.c
index 847e7be5ad..66aed0ad70 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -203,14 +203,6 @@ move_minibuffers_onto_frame (struct frame *of, bool for_deletion)
       zip_minibuffer_stacks (f->minibuffer_window, of->minibuffer_window);
       if (for_deletion && XFRAME (MB_frame) != of)
 	MB_frame = selected_frame;
-      if (!for_deletion
-	  && MINI_WINDOW_P (XWINDOW (FRAME_SELECTED_WINDOW (of))))
-	{
-	  Lisp_Object old_frame;
-	  XSETFRAME (old_frame, of);
-	  Fset_frame_selected_window (old_frame,
-				      Fframe_first_window (old_frame), Qnil);
-	}
     }
 }
 
diff --git a/src/xdisp.c b/src/xdisp.c
index 6963935666..7e166121df 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -12796,8 +12796,10 @@ 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)
+			     /* (NULL, current_buffer, Qnil, 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;


> martin

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 55412 <at> debbugs.gnu.org, rudalics <at> gmx.at, acm <at> muc.de, 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: Wed, 18 May 2022 19:03:32 +0300

> Date: Wed, 18 May 2022 15:49:36 +0000
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 55412 <at> debbugs.gnu.org, tanzer <at> swing.co.at,
>   acm <at> muc.de
> From: Alan Mackenzie <acm <at> muc.de>
> 
> > Suppose I want to calculate the sum of two numbers: number-1 is shown in
> > a buffer on frame-1, number-2 is show in a buffer on frame-2.  I start
> > typing M-: (+ on frame-1 then I do C-x o, mark number-1, type M-w, C-x o
> > and C-y to yank number-1 into the minibuffer.  Then I add a space to the
> > minibuffer, type C-x 5 o to go to frame-2, mark number-2, type M-w and
> > C-x 5 o to get back to frame-1.
> 
> > Ever since, that last C-x 5 o got me to the minibuffer window.  With the
> > proposed change, that C-x 5 o will get me to the window of number-1 and
> > I have to manually select the minibuffer window to yank number-2 there.
> 
> Please try the following patch, which may solve the above problem
> without hurting the bug fix.

Thanks, but shouldn't this somehow depend on the value of
minibuffer-follows-selected-frame?

Message #47 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, rudalics <at> gmx.at, 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: Wed, 18 May 2022 16:38:32 +0000

Hello, Eli.

On Wed, May 18, 2022 at 19:03:32 +0300, Eli Zaretskii wrote:
> > Date: Wed, 18 May 2022 15:49:36 +0000
> > Cc: Eli Zaretskii <eliz <at> gnu.org>, 55412 <at> debbugs.gnu.org, tanzer <at> swing.co.at,
> >   acm <at> muc.de
> > From: Alan Mackenzie <acm <at> muc.de>

> > > Suppose I want to calculate the sum of two numbers: number-1 is shown in
> > > a buffer on frame-1, number-2 is show in a buffer on frame-2.  I start
> > > typing M-: (+ on frame-1 then I do C-x o, mark number-1, type M-w, C-x o
> > > and C-y to yank number-1 into the minibuffer.  Then I add a space to the
> > > minibuffer, type C-x 5 o to go to frame-2, mark number-2, type M-w and
> > > C-x 5 o to get back to frame-1.

> > > Ever since, that last C-x 5 o got me to the minibuffer window.  With the
> > > proposed change, that C-x 5 o will get me to the window of number-1 and
> > > I have to manually select the minibuffer window to yank number-2 there.

> > Please try the following patch, which may solve the above problem
> > without hurting the bug fix.

> Thanks, but shouldn't this somehow depend on the value of
> minibuffer-follows-selected-frame?

I think it does.  If minibuffer-follows-selected-frame is nil, when we
return to a frame on which a minibuffer has been opened, the minibuffer
will still be there, so there is no need to select a different window.

If m-f-s-frame is t, and we have moved away from the frame on which a
minibuffer was opened, that minibuffer will have moved to the new frame.
It will either be terminated before we return to the original frame (in
which case we select a window different from the now invalid
mini-window), or the minibuffer returns to the original frame when we
switch back.

The critical criterion is whether there's a valid minibuffer in the
mini-window of the frame we switch to.  It doesn't really matter whether
that minibuffer has moved between frames, or was always there.  So,
maybe this process is independent of minibuffer-follow-selected-frame.
But I think it works.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 55412 <at> debbugs.gnu.org, rudalics <at> gmx.at, 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: Wed, 18 May 2022 19:51:54 +0300

> Date: Wed, 18 May 2022 16:38:32 +0000
> Cc: rudalics <at> gmx.at, 55412 <at> debbugs.gnu.org, tanzer <at> swing.co.at
> From: Alan Mackenzie <acm <at> muc.de>
> 
> > Thanks, but shouldn't this somehow depend on the value of
> > minibuffer-follows-selected-frame?
> 
> I think it does.  If minibuffer-follows-selected-frame is nil, when we
> return to a frame on which a minibuffer has been opened, the minibuffer
> will still be there, so there is no need to select a different window.
> 
> If m-f-s-frame is t, and we have moved away from the frame on which a
> minibuffer was opened, that minibuffer will have moved to the new frame.
> It will either be terminated before we return to the original frame (in
> which case we select a window different from the now invalid
> mini-window), or the minibuffer returns to the original frame when we
> switch back.
> 
> The critical criterion is whether there's a valid minibuffer in the
> mini-window of the frame we switch to.  It doesn't really matter whether
> that minibuffer has moved between frames, or was always there.  So,
> maybe this process is independent of minibuffer-follow-selected-frame.
> But I think it works.

It would be good to have some of these explanations in comments there.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 55412 <at> debbugs.gnu.org, tanzer <at> swing.co.at, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#55412: 28.1; In Emacs 28.1, using ':eval' in
 'frame-title-format' doesn't work properly
Date: Thu, 19 May 2022 09:18:01 +0200

> Please try the following patch, which may solve the above problem
> without hurting the bug fix.

It solves the above problem here.

Thanks, martin

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>, Alan Mackenzie <acm <at> muc.de>
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: Fri, 20 May 2022 10:23:17 +0200

> It would be good to have some of these explanations in comments there.

I understand that we want a quick solution for the present bug so it can
be included in Emacs 28.2.  But I still don't understand why nobody even
cared to try the patch I sent earlier.  With the current code, whenever
there are at least two frames present, 'gui_consider_frame_title' calls
via Fselect_window among others

redisplay_other_windows

Fredirect_frame_focus

resize_mini_window

move_minibuffers_onto_frame

and sets

last_nonminibuf_frame

internal_last_event_frame

Has anyone ever tried to understand the implications of all these?  Why
should redisplay indiscriminately set 'windows_or_buffers_changed' when
recomputing the frame title?  Why should we try to redirect frame focus
which is already sufficiently hairy by itself so hardly anyone really
understands what it does.  Why should formatting the frame title try to
resize a mini window or move minibuffers onto the selected frame?

Why set last_nonminibuf_frame which might affect 'display-buffer' and
apparently relies on some internal kludgery to set it precisely to the
same value it had before title line formatting started.  And why reset
internal_last_event_frame which also appears complicated enough to not
touch it unless you know precisely why and when.

Similar things happen with mode lines display - unwind_format_mode_line
apparently can call Fselect_window up to three times in a row with the
implications sketched above.

When trying to fix Bug#32777 I spent some time investigating these
issues but never found out why on earth we should call routines like
'select-frame' and 'select-window' from redisplay.  If there is any
rationale for these, it should be explained in comments first before
moving on to explain why moving minibuffers between frames can go awry.

martin

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 55412 <at> debbugs.gnu.org, acm <at> muc.de, 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: Fri, 20 May 2022 13:58:45 +0300

> Date: Fri, 20 May 2022 10:23:17 +0200
> Cc: 55412 <at> debbugs.gnu.org, tanzer <at> swing.co.at
> From: martin rudalics <rudalics <at> gmx.at>
> 
>  > It would be good to have some of these explanations in comments there.
> 
> I understand that we want a quick solution for the present bug so it can
> be included in Emacs 28.2.  But I still don't understand why nobody even
> cared to try the patch I sent earlier.

I don't think I understand what patch that is, but we could install
different solutions on master and the release branches.

In general, I prefer the old code to a new one, because the old code
by definition keeps old behavior, and thus runs lower risks of
breaking something.  But I won't object installing what is deemed a
better solution on master, even though it is riskier.

> With the current code, whenever there are at least two frames
> present, 'gui_consider_frame_title' calls via Fselect_window among
> others
> 
> redisplay_other_windows
> 
> Fredirect_frame_focus
> 
> resize_mini_window
> 
> move_minibuffers_onto_frame
> 
> and sets
> 
> last_nonminibuf_frame
> 
> internal_last_event_frame
> 
> Has anyone ever tried to understand the implications of all these?

Why would we need to do that?  This code was there for many years, so
its effects are by now a de-facto standard behavior of Emacs.  We
don't have human power and resources to revisit those decisions unless
someone submits a bug report, or unless some deep refactoring or
reimplementation of the code is taking place.

> When trying to fix Bug#32777 I spent some time investigating these
> issues but never found out why on earth we should call routines like
> 'select-frame' and 'select-window' from redisplay.

Well, now we know at least one reason: so that referencing
frame-parameters would what Lisp programs expect.

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

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

Hello, Martin.

On Fri, May 20, 2022 at 10:23:17 +0200, martin rudalics wrote:
>  > It would be good to have some of these explanations in comments there.

> I understand that we want a quick solution for the present bug so it can
> be included in Emacs 28.2.  But I still don't understand why nobody even
> cared to try the patch I sent earlier.

My apologies for not being aware of it.  Your post from last Sunday with
the patch was before I was in the thread, and I missed, in your
references to the patch, that it was a recent post in this thread.

I've just spent about an hour perusing the patch, and have the following
observations and questions.

The patch is too large to go into the emacs-28 branch, so for a "quick
safe fix", we'd still need the smaller patch I posted a small number of
days ago, or something like it.

with_window_selected is not re-entrant, since it uses a static data
structure.  Is this deliberate, or just a case of not yet making it
re-entrant?

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.

with_window_selected would add another "wild" setting of selected_frame,
this one outside of xdisp.c (in window.c) and I ask whether or not this
is a good thing.

I think the root of the problem your patch is trying to solve is that
the same C code is used for implementing C-x 5 o and lower level,
temporary, frame switches.  If this is the case, a good way of
proceeding would be to refactor do_switch_frame into a function
appropriate for lower level C calls, and the remainder for C-x 5 o.  For
example, the call to move_minibuffers_onto_frame is clearly needed for
C-x 5 o, but is a complicated nuisance for lower level C.  With such a
new extracted C function, we could replace the "selected_frame = ...;"
in xdisp.c by calls to this function.  Maybe.

> With the current code, whenever there are at least two frames present,
> 'gui_consider_frame_title' calls via Fselect_window among others

> redisplay_other_windows

> Fredirect_frame_focus

> resize_mini_window

> move_minibuffers_onto_frame

> and sets

> last_nonminibuf_frame

> internal_last_event_frame

Yes.  It also clears f->select_mini_window_flag, which I posted a
separate thread on emacs-devel about.  Here I think the problem is the
same as above: Fselect_window is a high level function for doing things
like C-x o, but we really need a low level function with which we could
do a controlled temporary switch to a different window, without the
unwanted complications of move_minibuffers_onto_frame etc..

> Has anyone ever tried to understand the implications of all these?  Why
> should redisplay indiscriminately set 'windows_or_buffers_changed' when
> recomputing the frame title?  Why should we try to redirect frame focus
> which is already sufficiently hairy by itself so hardly anyone really
> understands what it does.  Why should formatting the frame title try to
> resize a mini window or move minibuffers onto the selected frame?

I think my analysis above might point a way out of these problems.

> Why set last_nonminibuf_frame which might affect 'display-buffer' and
> apparently relies on some internal kludgery to set it precisely to the
> same value it had before title line formatting started.  And why reset
> internal_last_event_frame which also appears complicated enough to not
> touch it unless you know precisely why and when.

> Similar things happen with mode lines display - unwind_format_mode_line
> apparently can call Fselect_window up to three times in a row with the
> implications sketched above.

> When trying to fix Bug#32777 I spent some time investigating these
> issues but never found out why on earth we should call routines like
> 'select-frame' and 'select-window' from redisplay.  If there is any
> rationale for these, it should be explained in comments first before
> moving on to explain why moving minibuffers between frames can go awry.

I don't think redisplay should be calling Fselect_window or
do_switch_frame at all.  Instead we should call (not yet existing) lower
level functions.

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 55412 <at> debbugs.gnu.org, rudalics <at> gmx.at, 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: Fri, 20 May 2022 15:10:40 +0300

> Date: Fri, 20 May 2022 11:33:45 +0000
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 55412 <at> debbugs.gnu.org, tanzer <at> swing.co.at
> From: Alan Mackenzie <acm <at> muc.de>
> 
> I don't think redisplay should be calling Fselect_window or
> do_switch_frame at all.  Instead we should call (not yet existing) lower
> level functions.

Assuming those hypothetical lower-level functions will do enough of
Fselect_window to keep the semantics, I don't object.

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

From: Alan Mackenzie <acm <at> muc.de>
To: Christian Tanzer <tanzer <at> swing.co.at>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 55412 <at> debbugs.gnu.org, martin rudalics <rudalics <at> gmx.at>, acm <at> muc.de
Subject: Re: bug#55412: 28.1; In Emacs 28.1, using ':eval' in
 'frame-title-format' doesn't work properly
Date: Fri, 20 May 2022 20:39:06 +0000

Hello, Christian and 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'.

[ .... ]

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

[ .... ]

I have now committed the patch from Wednesday (slightly amended) to the
emacs-28 branch at savannah.  This should have fixed the bug.

Christian, if downloading the latest version from the savannah server is
inconvenient, please let me know, and I will send you the patch by email
so that you can patch your own version of Emacs 28.

[ .... ]

> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 55412 <at> debbugs.gnu.org, acm <at> muc.de, 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: Sat, 21 May 2022 10:32:41 +0200

>> When trying to fix Bug#32777 I spent some time investigating these
>> issues but never found out why on earth we should call routines like
>> 'select-frame' and 'select-window' from redisplay.
>
> Well, now we know at least one reason: so that referencing
> frame-parameters would what Lisp programs expect.

I don't understand what you mean here.  Please elaborate.

martin

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

From: martin rudalics <rudalics <at> gmx.at>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 55412 <at> debbugs.gnu.org, tanzer <at> swing.co.at, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#55412: 28.1; In Emacs 28.1, using ':eval' in
 'frame-title-format' doesn't work properly
Date: Sat, 21 May 2022 10:32:51 +0200

> with_window_selected is not re-entrant, since it uses a static data
> structure.  Is this deliberate, or just a case of not yet making it
> re-entrant?

You mean Vwith_window_selected_vector.  It's deliberate, just
transferred here from 'format_mode_line_unwind_data' which did the same.
Apparently the overhead for allocating a new vector during redisplay was
deemed as too expensive for making this re-entrant.

> 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.  This part of the redisplay code has been mended over
and over again in the past years, adding all those "special reasons" you
mention.

> with_window_selected would add another "wild" setting of selected_frame,
> this one outside of xdisp.c (in window.c) and I ask whether or not this
> is a good thing.

The canonical function to set selected_window is the static
select_window_1 and that's in window.c (with_window_selected sets
selected_window too but that's only a minor optimization).

> I think the root of the problem your patch is trying to solve is that
> the same C code is used for implementing C-x 5 o and lower level,
> temporary, frame switches.  If this is the case, a good way of
> proceeding would be to refactor do_switch_frame into a function
> appropriate for lower level C calls, and the remainder for C-x 5 o.  For
> example, the call to move_minibuffers_onto_frame is clearly needed for
> C-x 5 o, but is a complicated nuisance for lower level C.  With such a
> new extracted C function, we could replace the "selected_frame = ...;"
> in xdisp.c by calls to this function.  Maybe.

The redisplay code has to temporarily select a window also when there's
only one frame around in which case do_switch_frame wouldn't enter the
picture at all.  with_window_selected handles both cases.

> I don't think redisplay should be calling Fselect_window or
> do_switch_frame at all.  Instead we should call (not yet existing) lower
> level functions.

That's what with_window_selected and its unwind form have been designed
for.  Basically, any such code has to guarantee invariants like:

- The selected frame's selected window is the selected window.

- Code run within with_window_selected can rely on the fact that the
  selected window's buffer is current.

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.

One major advantage of with_window_selected is that then one can debug
functions like 'select-window', 'select-frame' or 'redirect-frame-focus'
without being continuously hassled by redisplay which here accounts for
nine out of ten calls of these functions at least and eventually caused
me to abandon a number of fixes for say Bug#32777, Bug#39977, Bug#24500
and Bug#24803.

martin

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 55412 <at> debbugs.gnu.org, acm <at> muc.de, 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: Sat, 21 May 2022 11:35:47 +0300

> Date: Sat, 21 May 2022 10:32:41 +0200
> Cc: acm <at> muc.de, 55412 <at> debbugs.gnu.org, tanzer <at> swing.co.at
> From: martin rudalics <rudalics <at> gmx.at>
> 
>  >> When trying to fix Bug#32777 I spent some time investigating these
>  >> issues but never found out why on earth we should call routines like
>  >> 'select-frame' and 'select-window' from redisplay.
>  >
>  > Well, now we know at least one reason: so that referencing
>  > frame-parameters would what Lisp programs expect.
> 
> I don't understand what you mean here.  Please elaborate.

See the OP's report: a :eval form in frame-title-format that
references a frame-parameter assumes that the frame whose title is
being evaluated is the selected-frame when the :eval form runs.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 55412 <at> debbugs.gnu.org, acm <at> muc.de, 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: Sat, 21 May 2022 11:59:43 +0300

> Date: Sat, 21 May 2022 10:32:51 +0200
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 55412 <at> debbugs.gnu.org, tanzer <at> swing.co.at
> From: martin rudalics <rudalics <at> 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.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: tanzer <at> gg32.com
Cc: 55412 <at> debbugs.gnu.org, acm <at> muc.de, rudalics <at> gmx.at
Subject: Re: bug#55412: 28.1; In Emacs 28.1, using ':eval' in
 'frame-title-format' doesn't work properly
Date: Sat, 21 May 2022 15:35:20 +0300

> Date: Sat, 21 May 2022 11:25:22 -0000
> From: tanzer <at> gg32.com
> Cc: martin rudalics <rudalics <at> gmx.at>, 55412 <at> debbugs.gnu.org
> 
> I needed to move back to Emacs 27.2 because there are some other bugs
> in 28.1 that I have no idea how to properly report:
> 
> - Emacs 28.1 most often crashes after loading a .emacs.desktop.
> 
>   It doesn't crash without a .emacs.desktop or with a simple one, but
>   at the moment I cannot start 28.1 on any of my usual .emacs.desktop
>   files without a crash. I suspect only a reboot will solve that.
> 
>   After the last reboot, I could start 28.1 once with a complex
>   .emacs.desktop, for a second (simultaneous) Emacs instance with a
>   different .emacs.desktop I had to use Emacs 27.2.
> 
>   Would it help to supply one of the crash dumps that macOS displayed
>   and how would I submit such a bug report?
> 
> - The second bug concerns .emacs.desktop.lock files. For some reason,
>   28.1 doesn't remove the lock file when exiting.
> 
>   Obviously, this isn't reproducible with `emacs -Q`. Again, how would
>   I submit such a bug report?

Yes, please submit bug reports for those issues with as much relevant
support data as you can, including any relevant customizations.  E.g.,
for desktop.el-related issues, please post the .emacs.desktop file
that causes those issues.

Thanks.

FTR, Emacs 28 never crashed on me due to anything related to
desktop.el, which I use all the time.  I also never saw any problems
with removing .emacs.desktop.lock with v28.1.

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

From: tanzer <at> gg32.com
To: Alan Mackenzie <acm <at> muc.de>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 55412 <at> debbugs.gnu.org, martin rudalics <rudalics <at> gmx.at>
Subject: Re: bug#55412: 28.1; In Emacs 28.1, using ':eval' in
 'frame-title-format' doesn't work properly
Date: Sat, 21 May 2022 11:25:22 -0000

Hello Alan and Eli,

Alan Mackenzie wrote at Fri, 20 May 2022 20:39:06 +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'.
>
> [ .... ]
>
> > 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:
>
> [ .... ]
>
> I have now committed the patch from Wednesday (slightly amended) to the
> emacs-28 branch at savannah.  This should have fixed the bug.

Thank you. I was very impressed how fast you guys moved!

> Christian, if downloading the latest version from the savannah server is
> inconvenient, please let me know, and I will send you the patch by email
> so that you can patch your own version of Emacs 28.

Unfortunately, I'll have to wait for 28.2. But thanks for the offer
nevertheless.

I needed to move back to Emacs 27.2 because there are some other bugs
in 28.1 that I have no idea how to properly report:

- Emacs 28.1 most often crashes after loading a .emacs.desktop.

  It doesn't crash without a .emacs.desktop or with a simple one, but
  at the moment I cannot start 28.1 on any of my usual .emacs.desktop
  files without a crash. I suspect only a reboot will solve that.

  After the last reboot, I could start 28.1 once with a complex
  .emacs.desktop, for a second (simultaneous) Emacs instance with a
  different .emacs.desktop I had to use Emacs 27.2.

  Would it help to supply one of the crash dumps that macOS displayed
  and how would I submit such a bug report?

- The second bug concerns .emacs.desktop.lock files. For some reason,
  28.1 doesn't remove the lock file when exiting.

  Obviously, this isn't reproducible with `emacs -Q`. Again, how would
  I submit such a bug report?

Thanks again and have a nice weekend,

Christian

PS: ATM, I'm not set up to compile Emacs myself as I temporarily moved
    into a very small house and don't have any Linux machine here. I'm
    not masochistic enough to setup up a compilation environment on
    the little Macbook I have (which is severly lacking on disc space).

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

From: Alan Mackenzie <acm <at> muc.de>
To: tanzer <at> gg32.com
Cc: 55412-done <at> debbugs.gnu.org, martin rudalics <rudalics <at> gmx.at>,
 Eli Zaretskii <eliz <at> gnu.org>, acm <at> muc.de
Subject: Re: bug#55412: 28.1; In Emacs 28.1, using ':eval' in
 'frame-title-format' doesn't work properly
Date: Sun, 22 May 2022 17:34:18 +0000

Hello, Christian.

On Sat, May 21, 2022 at 11:25:22 -0000, tanzer <at> gg32.com wrote:

> Hello Alan and Eli,

> Alan Mackenzie wrote at Fri, 20 May 2022 20:39:06 +0000:

> > On Sat, May 14, 2022 at 19:58:13 +0300, Eli Zaretskii wrote:

> > I have now committed the patch from Wednesday (slightly amended) to the
> > emacs-28 branch at savannah.  This should have fixed the bug.

> Thank you. I was very impressed how fast you guys moved!

OK, thanks!  I'm now closing the bug with this post.

> I needed to move back to Emacs 27.2 because there are some other bugs
> in 28.1 that I have no idea how to properly report:

[ .... ]

I'm sorry about these, and hope we manage to get them fixed, too!

> Thanks again and have a nice weekend,

You too!

> Christian

> PS: ATM, I'm not set up to compile Emacs myself as I temporarily moved
>     into a very small house and don't have any Linux machine here. I'm
>     not masochistic enough to setup up a compilation environment on
>     the little Macbook I have (which is severly lacking on disc space).

OK.

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