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 16:13:24 +0200 Message-ID: <83v8k4cp2z.fsf@gnu.org> References: <87zg9hqflv.fsf@telefonica.net> <83fsb8e8yr.fsf@gnu.org> <87mt5gqshv.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="30355"; 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 15:14:12 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 1pRw4S-0007dH-58 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 14 Feb 2023 15:14:12 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pRw4K-0007XN-U1; Tue, 14 Feb 2023 09:14: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 1pRw4J-0007Nt-0y for bug-gnu-emacs@gnu.org; Tue, 14 Feb 2023 09:14: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 1pRw4I-0004Tq-O2 for bug-gnu-emacs@gnu.org; Tue, 14 Feb 2023 09:14:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pRw4I-0001xd-Io for bug-gnu-emacs@gnu.org; Tue, 14 Feb 2023 09:14:02 -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 14:14:02 +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.16763840347515 (code B ref 61496); Tue, 14 Feb 2023 14:14:02 +0000 Original-Received: (at 61496) by debbugs.gnu.org; 14 Feb 2023 14:13:54 +0000 Original-Received: from localhost ([127.0.0.1]:52967 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pRw4A-0001x8-9C for submit@debbugs.gnu.org; Tue, 14 Feb 2023 09:13:54 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:55562) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pRw49-0001wu-1k for 61496@debbugs.gnu.org; Tue, 14 Feb 2023 09:13:53 -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 1pRw43-0004SB-7o; Tue, 14 Feb 2023 09:13:47 -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=PK3zA6IS1mCJQPmaaGbr8EoZpHeXkciyArk1L8QbJ88=; b=g7rt8GWxUx+AZJ1BOlhg 38MrDBgbEO/wVEu/oU1BUlg/MrR5xqbWHXh9kaL5koQfiBQam6lLfeZw7PmPA3CnAEo7WxqLgqiqo NCB1wpwpTK7Tq8uU/uECRKBLnK9WeRq+SD/0qkXWgoBlX1uH4+vDpXJydpzPFSSwKcs/EDKUPEeJS rxl2+Jb8lMAcDjiY/i5n8kcHFy7SKtFNizedFBwwMes5TIBZepIg86MdLjaxORCWpZ4nEHhBkoZDb vLHtEKm7hjf2Xwn5r4GBZXBVxA+3MkEp8einvdNn51zR74/mQ2Zb3WNgFsIc9K5s8i4cPxyGp3NQs fT7bmd1vY7a2Fw==; 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 1pRw42-0008NB-Iy; Tue, 14 Feb 2023 09:13:46 -0500 In-Reply-To: <87mt5gqshv.fsf@telefonica.net> (message from =?UTF-8?Q?=C3=93scar?= Fuentes on Tue, 14 Feb 2023 14:35:56 +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:255583 Archived-At: > From: Óscar Fuentes > Cc: 61496@debbugs.gnu.org > Date: Tue, 14 Feb 2023 14:35:56 +0100 > > Eli Zaretskii writes: > > > 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. > > The whole point of this change is to not break user's setup when they > upgrade to 29. If the user must fix his config, he may as well set > icon-title-format and be done with it. > > OTOH, there is no possible breakage by changing the default. (Famous last words.) Seriously, though: I can easily concoct a situation where this change will break someone's setup: imagine that someone's customizations expect icon-title-format to be a string. Boom! > > . 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. > > The purpose of changing the default is based partly on the idea that, > very likely, the user will want to keep icon-title-format in sync with > frame-title-format. So not having to do anything to achieve that is a > feature, not a bug. We are mis-communicating. My point is that the value nil means "don't display this". E.g., try setting mode-line-format or frame-title-format to nil, and observe the effect. So setting it to nil could mean the user really doesn't want the title be displayed. Thus, usurping the nil value to mean "use frame-title-format instead" could be a backward-incompatible change. By contrast, I don't expect anyone to set the value to t, because doing so would require intimate knowledge of the display-engine internals (which in this case treat nil and t the same). So using t for this special purpose is better from backward-compatibility POV. It is also more logical, since the user _does_ want a title, just the "default" one. > > and it is quite possible that someone out there does want/expect > > the default value to be a string. > > I have no idea how this can be. Please believe me and my gray hair: with Emacs, anything that is just possible is usually done by someone out there. > > Thus, I think we should leave the > > change of the default value for some future release. > > ... which, as I explained, will require another round of fixes on user's > config to avoid the same problem when 30 is released. No, it won't. If the user sets icon-title-format to t, that will work with Emacs 29, and will still work if and when we make t the default value in future versions. > If this is your final decision, it's better to discard the whole > proposal, as it gives little benefit. I disagree. I think it will allow you and others in your situation to have the problem solved, while not risking breaking someone's unrelated customizations. I don't understand the urge to have it solved automagically, even for those who are affected by the changes in Emacs 29.