From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?=C3=93scar?= Fuentes Newsgroups: gmane.emacs.bugs Subject: bug#61496: 30.0.50; Default value of icon-title-format Date: Fri, 17 Feb 2023 02:10:05 +0100 Message-ID: <87sff5p05u.fsf@telefonica.net> References: <87zg9hqflv.fsf@telefonica.net> <83fsb8e8yr.fsf@gnu.org> <87mt5gqshv.fsf@telefonica.net> <83v8k4cp2z.fsf@gnu.org> <87y1p0tj05.fsf@yahoo.com> <83mt5gcnqb.fsf@gnu.org> <87bklwqoq6.fsf@telefonica.net> <83edqscfzh.fsf@gnu.org> <87o7pto9zb.fsf@bernoul.li> <83h6vl35c4.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27790"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: luangruo@yahoo.com, Jonas Bernoulli , 61496@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Feb 17 02:11:28 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 1pSpHb-000762-Tn for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 17 Feb 2023 02:11:27 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pSpHD-0001Gr-QZ; Thu, 16 Feb 2023 20:11:03 -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 1pSpHC-0001Gi-Uc for bug-gnu-emacs@gnu.org; Thu, 16 Feb 2023 20:11:02 -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 1pSpHC-0004tT-NV for bug-gnu-emacs@gnu.org; Thu, 16 Feb 2023 20:11:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pSpHC-0006Nz-FH for bug-gnu-emacs@gnu.org; Thu, 16 Feb 2023 20:11:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?=C3=93scar?= Fuentes Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 17 Feb 2023 01:11: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.167659621824494 (code B ref 61496); Fri, 17 Feb 2023 01:11:02 +0000 Original-Received: (at 61496) by debbugs.gnu.org; 17 Feb 2023 01:10:18 +0000 Original-Received: from localhost ([127.0.0.1]:38059 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pSpGT-0006Mz-Cn for submit@debbugs.gnu.org; Thu, 16 Feb 2023 20:10:17 -0500 Original-Received: from relayout03.e.movistar.es ([86.109.101.203]:35669 helo=relayout03-redir.e.movistar.es) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pSpGR-0006Mi-E6 for 61496@debbugs.gnu.org; Thu, 16 Feb 2023 20:10:16 -0500 Original-Received: from sky (73.red-81-39-121.dynamicip.rima-tde.net [81.39.121.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: 981711563@telefonica.net) by relayout03.e.movistar.es (Postfix) with ESMTPSA id 4PHtyk48DLzMlJx; Fri, 17 Feb 2023 02:10:05 +0100 (CET) In-Reply-To: <83h6vl35c4.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 16 Feb 2023 19:09:15 +0200") X-TnetOut-Country: IP: 81.39.121.73 | Country: ES X-TnetOut-Information: AntiSPAM and AntiVIRUS on relayout03 X-TnetOut-MsgID: 4PHtyk48DLzMlJx.AC208 X-TnetOut-SpamCheck: no es spam, clean X-TnetOut-From: ofv@wanadoo.es X-TnetOut-Watermark: 1677201008.97991@fXE1go4+XmNbGNJNkA7dKA 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:255843 Archived-At: Eli Zaretskii writes: > [Forwarding message by Jonas to the bug tracker] > >> From: Jonas Bernoulli >> Date: Thu, 16 Feb 2023 17:23:20 +0100 >>=20 >> A day after this discussion began, I opened a duplicate of sorts >> (bug#61538). Eli asked me to express my opinion here. >>=20 >> I was inclined to agree with =C3=93scar after reading this discussion, b= ut >> after experimenting a bit, I am not so sure anymore. >>=20 >> 1. I have not actually experienced a regression. I was happy to use the >> default values for icon- and frame-title-format for a long time (I >> used the uniquify package to display a bit more information than just >> the nondirectory part of the filename). It is a coincidence that I >> just now decided that I want to instead use the absolute filename as >> the frame title but continue to display some abbreviation in the >> mode-line. >>=20 >> 2. Apparently icon-frame-title was broken since 24.x. Reading this >> thread I assumed that means that variable was just ignored. But I >> just experimented with these variables in 28.2 and they both appear >> to behave as documented. That's not what I observe here: $ src/emacs -Q C-u M-x version GNU Emacs 28.1 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16= .0) of 2023-02-17 (setq icon-title-format "hello") C-l (force redisplay, just in case) After minimizing the frame with the mouse or pressing C-z, the text on KDE taskbar does not change. Doing the same in 29 the text changes. >> Before I can really form an opinion on whether the default should >> be changed in 29.1 or 30.1, I need you to tell me how the behavior >> changed from 28.2 to 29.0.60. >>=20 >> I think the default for icon-frame-title should be "the same as for >> frames that are not iconified" and that should be expressed using t as >> the value. As far as I currently understand it, that would be a change >> in behavior. Well, if icon-frame-title worked, changing its default would indeed be a change in behavior, but if it is true that it was broken since ~24, the act of simply fixing it *is* a change in behavior (as we both experienced) respect to the previous 4 major releases. The argument about breaking the configs that require icon-title-format to be a string is too hypothetical, IMAO, apart from being easy to detect and fix by the user. My guess is that icon-title-format was implemented for the benefit of the users of certain desktop environments that, instead of minimizing a frame (window) to a taskbar, they literally iconified the window, with little horizontal space for the title below the icon and, probably, difficulty to tell apart the iconified-but-running application from the rest of icons on the desktop, so icon-title-format was quite handy. Nowadays, taskbars either provide lots of room for a title or don't show the title at all, so the need for icon-title-format is less pressing, as demonstrated by the absence of bug reports about it being broken until Po noticed it by chance. I'm not saying that it is bad to have that feature, though.