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#61496: 30.0.50; Default value of icon-title-format Date: Tue, 14 Feb 2023 14:18:36 +0200 Message-ID: <83fsb8e8yr.fsf@gnu.org> References: <87zg9hqflv.fsf@telefonica.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39704"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 61496@debbugs.gnu.org To: =?UTF-8?Q?=C3=93scar?= Fuentes Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Feb 14 13:20:16 2023 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 1pRuIA-000A5m-ML for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 14 Feb 2023 13:20:14 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pRuI0-0005So-K6; Tue, 14 Feb 2023 07:20:04 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pRuHz-0005Sb-2e for bug-gnu-emacs@gnu.org; Tue, 14 Feb 2023 07:20:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pRuHy-0004ZD-IF for bug-gnu-emacs@gnu.org; Tue, 14 Feb 2023 07:20:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pRuHx-0004hy-US for bug-gnu-emacs@gnu.org; Tue, 14 Feb 2023 07:20:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 14 Feb 2023 12:20:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61496 X-GNU-PR-Package: emacs Original-Received: via spool by 61496-submit@debbugs.gnu.org id=B61496.167637715018030 (code B ref 61496); Tue, 14 Feb 2023 12:20:01 +0000 Original-Received: (at 61496) by debbugs.gnu.org; 14 Feb 2023 12:19:10 +0000 Original-Received: from localhost ([127.0.0.1]:52781 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pRuH7-0004gk-Jr for submit@debbugs.gnu.org; Tue, 14 Feb 2023 07:19:10 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:46730) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pRuH4-0004gD-3u for 61496@debbugs.gnu.org; Tue, 14 Feb 2023 07:19:08 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pRuGy-0004NL-5M; Tue, 14 Feb 2023 07:19:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=zj+fedZ0DJgayk+qBS1fKgPGfRD3MvRREXSC+kzocZs=; b=qDA2t0TJTQFanqCDxBxD FSX+a5bFzxzO7cqtFx4AWihn9JWi+QQXP6nPLJXtVG8aYSW3DRwwzEJpi2u3SWQlxW43qynOTOkz6 e/OTTpoltas0A+r/7SUZBAgqfD6hHEdTLSo+ZSs0hNyOULJVEbDaPrKBCQbPJcRN+q+8Own3wx5G2 afNY9TNClhJ90l1/GAxVKVoLjmffc6CYM4HfVqNA8QIrJO/fvERf193nc+kcFw10U1gVJV2oz2N2y prZCYi0L2gCGQCa7ZpR8/zfqFF55sCPeS4v09Q4Inh7HXlmk/ZO0c/QEH0PdBWHQ18bXauzYt1VTe PjaERtXv8Kjdgg==; Original-Received: from [87.69.77.57] (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 1pRuGv-0004vY-UW; Tue, 14 Feb 2023 07:18:58 -0500 In-Reply-To: <87zg9hqflv.fsf@telefonica.net> (message from =?UTF-8?Q?=C3=93scar?= Fuentes on Tue, 14 Feb 2023 01:02:04 +0100) 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:255570 Archived-At: > From: Óscar Fuentes > Date: Tue, 14 Feb 2023 01:02:04 +0100 > > > AFAIK icon-title-format was broken since long time ago (possibly for > several major releases) and it was fixed recently. > > I propose that its default value should be nil, and interpret that value > as "same as frame-title-format". That's why: > > 1. The case of having an specific frame title when it is iconified seems > to me as way less frequent than expecting that the frame keeps the > same title. > > 2. After upgrading to Emacs 29, users that set frame-title-format will > see how frames change their title when iconified. > > 3. There are mechanisms for applying settings or performing actions > depending on the title of a frame (KDE Window Rules and scripts based > on xdotool, for instance.) For keeping those mechanisms on a working > state with Emacs 29, the user must ensure that either it keeps > icon-title-format synced with frame-title-format and/or his scripts > must be adapted. Without that, any config that depends on the > content's of the frame title will be broken (unless the user already > set icon-title-format, but it would be surprising if he did, as that > setting had no effect until now.) > > Having a working icon-title-format, in practice, is a new feature, so > defining a new default for it shouldn't have any impact. Certainly, it > will not have a visible effect compared to recent Emacs releases. > However, keeping its current default value may cause confusion and > breakage for any user that sets frame-title-format on his config. > > The required change in code is simple enough: > > src/xdisp.c | 3 ++- > > modified src/xdisp.c > @@ -13424,7 +13424,8 @@ gui_consider_frame_title (Lisp_Object frame) > > 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; > + fmt = FRAME_ICONIFIED_P (f) && !NILP (Vicon_title_format) ? > + Vicon_title_format : Vframe_title_format; > > mode_line_target = MODE_LINE_TITLE; > title_start = MODE_LINE_NOPROP_LEN (0); > > ... plus a trivial doc change on its DEFVAR_LISP and initialization. > > If this proposal is acceptable, it should be applied to Emacs 29, to > avoid putting ourselves on a similar scenario when Emacs 30 is released. I agree with adding a feature that will allow to keep icon-title-format and frame-title-format identical. However: . I don't want to make that the default: it's too late for such changes on the emacs-29 branch. . I suggest that the "special" value which means "use frame-title-format" will be t, not nil, so that users who want it set it explicitly, not by some omission. (Code-wise, this is not important, since the code treats both nil and t the same: it produces nothing. So using t or nil is backward-compatible, in the sense that older Emacsen will not crash.) I understand that you think the more radical change you propose is for the better, and "no one can possibly suffer of be against it", but I think you are not very objective, being a victim of the problem, and it is quite possible that someone out there does want/expect the default value to be a string. Thus, I think we should leave the change of the default value for some future release. So: okay for changing xdisp.c, just using EQ (Qt, ...), not NILP, but please don't change the default value of icon-title-format. Also, this change needs a suitable NEWS entry and appropriate changes for the doc string and the ELisp manual. Thanks.