From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: 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 Message-ID: <5b197424-4849-9771-ff1d-41b7a8295ba2@gmx.at> 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=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40718"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 55412@debbugs.gnu.org, tanzer@swing.co.at, Eli Zaretskii To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat May 21 10:37:28 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 1nsKc3-000APw-SX for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 21 May 2022 10:37:27 +0200 Original-Received: from localhost ([::1]:51372 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nsKc2-0001CK-CX for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 21 May 2022 04:37:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52400) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nsKYk-0007XL-RZ for bug-gnu-emacs@gnu.org; Sat, 21 May 2022 04:34:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46770) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nsKYk-0003h8-JU for bug-gnu-emacs@gnu.org; Sat, 21 May 2022 04:34:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nsKYk-0007xj-GW for bug-gnu-emacs@gnu.org; Sat, 21 May 2022 04:34:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 21 May 2022 08:34:02 +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.165312198930531 (code B ref 55412); Sat, 21 May 2022 08:34:02 +0000 Original-Received: (at 55412) by debbugs.gnu.org; 21 May 2022 08:33:09 +0000 Original-Received: from localhost ([127.0.0.1]:40666 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nsKXs-0007wN-SV for submit@debbugs.gnu.org; Sat, 21 May 2022 04:33:09 -0400 Original-Received: from mout.gmx.net ([212.227.17.22]:47271) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nsKXn-0007vb-9W for 55412@debbugs.gnu.org; Sat, 21 May 2022 04:33:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1653121972; bh=XBqIbaGljRx1X4E/AwmShiDDPeIovEU3cdHw0mFMUDY=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:In-Reply-To; b=LP0VW7kov1hePo4ksLKGkAF5T4E3ISsq8XbmyaOzutvN7eQ7SYXnkWDLEoyXdjZFN 5To5p32jv/zRQQmK1GzCK3q7QnUWTeKWxfpU1Z6JNxBH4b+nYVESg8wK4coX2twREF T2FVrlrnzMy6GNWHys7zeZ2akKhLWZr6yaDc1ZBE= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.102] ([212.95.5.31]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MtOKc-1na7hd3N2E-00utgk; Sat, 21 May 2022 10:32:51 +0200 Content-Language: en-US In-Reply-To: X-Provags-ID: V03:K1:k0veoLrRZKJkS8f2stESpc7Ai4c3DMt0Cio9e4SnbZhEtJCHQgL SGjnpwbBdRAEzkmbzAB29I03ycJTMakFCPtxTg8uYBjjlN4qVRg1fIcvFpKKaESTTRWb+OK wPX2mlLpliWHzodpBZ+Biixc7gaLPfGzctxx4n4CRLAjSjrr0QFN0hUNcL6fvGsLfNcCr1L EkHAXE3gAoCanw2RCRouw== X-UI-Out-Filterresults: notjunk:1;V03:K0:8zoGq8alH/I=:eAM4wf5UgMKmdOIqJqysG2 LSrbtjq9mFHNxJjKNH1wq6ASrJHjSaJJap4Qy4CJoexCdE0BixJ94HuXOOOZL5GX0EQhGjpoc 0LICHMhqullienyafGvqnnvVpm9rpN5RpYG6mIo8cAd9mC2A0rQboZyOEszzp07tk8f7Xv8Hl kZoB73GylGAW2pyMwVlK3cTvfs9B2kMj7T191j41VQyaZJKCw4CtBa9UNd78iRKq3tEOkFz9Z 1Zg45DZSLqHSDPOAe9EY0o+TBrkrBxvQnbptx4Ce5Xs/zQnnthnPwdhxbGUh0AX2k6xjN0bJR 7HV62IRVKszQJRfjSi9lLoeuqJ8yid9Q5PXQmf6rw5RHxbk/EXeKVWxjHv/jHsOFMEnAyIVJO cO+rw9QND3GNcqmNyWLJ4G3zLXva0+Ge6BUb8BMCkMuyV609Hj1kPQeDlQ1FTaGS7Xlkjex92 kM0kisKg82HXovlMgPIHvYbOyING2uTGszkUTFoL2cVffAPC120uScNpkludyP368pK4KiE91 R11thhgekRRs9IYGt98cSCWCPP6w8WDxQiPMarxkEhvQcZsS+jniSYzvMAsQKiM1BvbFnURky 2VBlM2/0ROVqv7LGiTzKqBa6tmj4qNgCf6az5szPqt0L1O0bmftfe50BKEGU/xo0rLzo4odVA 8Mp8xpE4ClnGYo6vYyDBcugX9XVVtDz1Tf4D2UpR63HcqDHwEDmoe+Z4T3T9jirk3rnUjbleS gFlepUuZmpqucMii3LZ9PPHx8z3cpDu7keyfSZHJB4CX3lL9QKRDCh+lofiVar1EpitbXe78 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:232805 Archived-At: > 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