From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii 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 11:59:43 +0300 Message-ID: <83zgjb8dmo.fsf@gnu.org> 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> <5b197424-4849-9771-ff1d-41b7a8295ba2@gmx.at> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29285"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 55412@debbugs.gnu.org, acm@muc.de, tanzer@swing.co.at To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat May 21 11:01: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 1nsKz6-0007Si-Fw for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 21 May 2022 11:01:16 +0200 Original-Received: from localhost ([::1]:38992 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nsKz5-0004Gi-1C for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 21 May 2022 05:01:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55850) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nsKys-0004GM-CT for bug-gnu-emacs@gnu.org; Sat, 21 May 2022 05:01:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46797) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nsKys-0007ju-1F for bug-gnu-emacs@gnu.org; Sat, 21 May 2022 05:01:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nsKyr-0000Hm-R5 for bug-gnu-emacs@gnu.org; Sat, 21 May 2022 05:01:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 21 May 2022 09:01: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.1653123605941 (code B ref 55412); Sat, 21 May 2022 09:01:01 +0000 Original-Received: (at 55412) by debbugs.gnu.org; 21 May 2022 09:00:05 +0000 Original-Received: from localhost ([127.0.0.1]:40694 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nsKxw-0000F7-9V for submit@debbugs.gnu.org; Sat, 21 May 2022 05:00:04 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:34102) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nsKxq-0000E0-KY for 55412@debbugs.gnu.org; Sat, 21 May 2022 05:00:02 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:49324) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nsKxj-0007NF-8P; Sat, 21 May 2022 04:59:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=GUgnaPdwMwmzCtrIO/+yxgEOUS+wn+FYoOBH32UTFHI=; b=LN9al0c888ND 5jIz95C0dBtdfvwam4OkjQnsJZHdYWtCKt6Hg9fquNfJq8RJ+66GcnhRWaC9Ru6gI7XBpbGEPAQEw thnCecuyA4NZNQQohwI4L3kol6W8jypDOvH9JkvMuDoW58ET66QaeUVnvG3JO2h8L0tY7IBGTzNWW rtmzej944fRaDbwwCQi8eUfT7yvWADGzezthXXd+1+z+c1y2aPN/QeUZZ/pePbBLabc6r05TpQjdB FN79juzn4y6Q4pFL95G5+WoMOpjJxboVoxaO1sNJFaXTDYU+bUZgRpRrernR0ELDK0X8Tz4FJNGju Z1p+lIG0Wk8vj/lghvbQNQ==; Original-Received: from [87.69.77.57] (port=2517 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nsKxi-0007iI-Gn; Sat, 21 May 2022 04:59:50 -0400 In-Reply-To: <5b197424-4849-9771-ff1d-41b7a8295ba2@gmx.at> (message from martin rudalics on Sat, 21 May 2022 10:32:51 +0200) 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:232808 Archived-At: > Date: Sat, 21 May 2022 10:32:51 +0200 > Cc: Eli Zaretskii , 55412@debbugs.gnu.org, tanzer@swing.co.at > From: martin rudalics > > > 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.