From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: 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 Message-ID: References: <838rr4kq56.fsf@gnu.org> <87d23565-b8ba-3b08-0d10-068be3b0c5fd@gmx.at> <83leuzf4zk.fsf@gnu.org> <83sfp6eskr.fsf@gnu.org> <83mtfeeqc5.fsf@gnu.org> <408f7b88-2000-bd10-bd9d-4e06018e8ff0@gmx.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26018"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 55412@debbugs.gnu.org, tanzer@swing.co.at, Eli Zaretskii To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri May 20 13:34:16 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ns0tc-0006YY-2A for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 20 May 2022 13:34:16 +0200 Original-Received: from localhost ([::1]:50954 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ns0ta-0000Sp-M1 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 20 May 2022 07:34:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49338) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ns0tO-0000QV-8n for bug-gnu-emacs@gnu.org; Fri, 20 May 2022 07:34:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:43912) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ns0tN-0001XN-Vz for bug-gnu-emacs@gnu.org; Fri, 20 May 2022 07:34:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ns0tN-0003cX-TT for bug-gnu-emacs@gnu.org; Fri, 20 May 2022 07:34:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 20 May 2022 11:34:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 55412 X-GNU-PR-Package: emacs Original-Received: via spool by 55412-submit@debbugs.gnu.org id=B55412.165304643413904 (code B ref 55412); Fri, 20 May 2022 11:34:01 +0000 Original-Received: (at 55412) by debbugs.gnu.org; 20 May 2022 11:33:54 +0000 Original-Received: from localhost ([127.0.0.1]:37809 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ns0tG-0003cC-5H for submit@debbugs.gnu.org; Fri, 20 May 2022 07:33:54 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:19403 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1ns0tE-0003by-Fy for 55412@debbugs.gnu.org; Fri, 20 May 2022 07:33:53 -0400 Original-Received: (qmail 85922 invoked by uid 3782); 20 May 2022 11:33:46 -0000 Original-Received: from acm.muc.de (p4fe15826.dip0.t-ipconnect.de [79.225.88.38]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 20 May 2022 13:33:46 +0200 Original-Received: (qmail 6042 invoked by uid 1000); 20 May 2022 11:33:45 -0000 Content-Disposition: inline In-Reply-To: <408f7b88-2000-bd10-bd9d-4e06018e8ff0@gmx.at> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:232737 Archived-At: 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).