bug#61496: 30.0.50; Default value of icon-title-format

["Óscar Fuentes" <ofv@wanadoo.es>]

Eli Zaretskii <eliz@gnu.org> writes:

> [Forwarding message by Jonas to the bug tracker]
>
>> From: Jonas Bernoulli <jonas@bernoul.li>
>> Date: Thu, 16 Feb 2023 17:23:20 +0100
>> 
>> A day after this discussion began, I opened a duplicate of sorts
>> (bug#61538).  Eli asked me to express my opinion here.
>> 
>> I was inclined to agree with Óscar after reading this discussion, but
>> after experimenting a bit, I am not so sure anymore.
>> 
>> 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.
>> 
>> 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.
>> 
>> 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.