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

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

[Óscar Fuentes]

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.

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Óscar Fuentes <ofv@wanadoo.es> writes:

> 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 this change, but please note that our coding style means
you should write:

  fmt = (FRAME_ICONIFIED_P && !NILP (Vicon_title_format)
         ? Vicon_title_format : Vframe_title_format);

instead.

Thanks.

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

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> 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.

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

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> 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.

>   . 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.

> (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,

Yes, wasting several hours made me aware of the impact this change may
have. This made my judgement quite *objetive* about it :-)

> 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. OTOH, the problems caused by the current
state are obvious and real.

> 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.

> 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.

If this is your final decision, it's better to discard the whole
proposal, as it gives little benefit. Then, mentioning in NEWS that
icon-title-format is back is even more important because of the problems
mentioned.

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

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Cc: 61496@debbugs.gnu.org
> Date: Tue, 14 Feb 2023 14:35:56 +0100
> 
> Eli Zaretskii <eliz@gnu.org> 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.

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

BTW, for the record:

icon-title-format stopped working after some Emacs 24.x release, and was
only fixed in Emacs 29.

I don't know if that's relevant or not.  I have no opinion as to the
arguments you or Oscar have presented, as I have not yet read them, but
I am in favor of his change.

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Óscar Fuentes <ofv@wanadoo.es>,  61496@debbugs.gnu.org
> Date: Tue, 14 Feb 2023 22:32:42 +0800
> 
> BTW, for the record:
> 
> icon-title-format stopped working after some Emacs 24.x release, and was
> only fixed in Emacs 29.
> 
> I don't know if that's relevant or not.  I have no opinion as to the
> arguments you or Oscar have presented, as I have not yet read them, but
> I am in favor of his change.

I'm not opposed to the change, I just asked for minor changes in some
details of the change.

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

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> BTW, for the record:
>> 
>> icon-title-format stopped working after some Emacs 24.x release, and was
>> only fixed in Emacs 29.
>> 
>> I don't know if that's relevant or not.  I have no opinion as to the
>> arguments you or Oscar have presented, as I have not yet read them, but
>> I am in favor of his change.
>
> I'm not opposed to the change, I just asked for minor changes in some
> details of the change.

The core of my proposal, is changing icon-title-format's default, so
users (and external scripts!) will keep observing the same behavior
after upgrading to 29.

My understanding is that you opposed this change in defaults. If I'm
wrong about this, my apologies.

OTOH, I think that what Po just said speak volumes about the abundance
and importance of icon-title-format on user's config.

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

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Cc: Po Lu <luangruo@yahoo.com>,  61496@debbugs.gnu.org
> Date: Tue, 14 Feb 2023 15:57:21 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> BTW, for the record:
> >> 
> >> icon-title-format stopped working after some Emacs 24.x release, and was
> >> only fixed in Emacs 29.
> >> 
> >> I don't know if that's relevant or not.  I have no opinion as to the
> >> arguments you or Oscar have presented, as I have not yet read them, but
> >> I am in favor of his change.
> >
> > I'm not opposed to the change, I just asked for minor changes in some
> > details of the change.
> 
> The core of my proposal, is changing icon-title-format's default, so
> users (and external scripts!) will keep observing the same behavior
> after upgrading to 29.

I can't believe that we are actually making such a fuss about asking
the affected users to add a single line to their init files:

  (setq icon-title-format t)

At times, bugfixes end up producing backward-incompatible behavior,
and when that happens, we call those cases out in NEWS and tell users
how to unbreak whatever could be broken by the changes.  Why cannot
that be done in this case?

Please understand: the change you propose, at the 95th minute, _is_
backward-incompatible.  You argue that no one could possibly not want
such a change, but I have too much gray hair from watching such
assumptions and firm opinions defeated by the bitter reality to
believe this.  The only relatively reliable judge is user feedback,
and we don't have time to wait for that for Emacs 29.  So I cannot
agree to what you propose, and urge you to see the dangers.

But if you think the change in Emacs 29 behavior in this aspect is so
grave, we could instead revert that change on emacs-29, leaving
icon-title-format broken as it was since Emacs 24, and leave the fix
only on master.  Then on master we could perhaps change the default
more easily.

> OTOH, I think that what Po just said speak volumes about the abundance
> and importance of icon-title-format on user's config.

Granted, I took his opinion into account.

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

[Eli Zaretskii]

> 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.

Thanks for chiming in.

> 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.
> 
>    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, too, thought this was fixed only for Emacs 29, but maybe I
misunderstood.

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

[Eli Zaretskii]

[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.
> 
>    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.
> 

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

[Óscar Fuentes]

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.

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

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Óscar Fuentes <ofv@wanadoo.es> writes:

> 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.

Indeed, another feature that has been broken for even longer is the
ability to set a real bitmap icon for the icon window.  I will
eventually get around to fixing that.

I guess no post-2000 window manager even displays icon windows any more.

As for why it works for Jonas, I'm not sure.  Maybe his window manager
somehow convinced Emacs to redisplay the title bar.

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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Jonas Bernoulli <jonas@bernoul.li>,
>   61496@debbugs.gnu.org
> Date: Fri, 17 Feb 2023 10:47:14 +0800
> 
> Óscar Fuentes <ofv@wanadoo.es> writes:
> 
> > 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.
> 
> Indeed, another feature that has been broken for even longer is the
> ability to set a real bitmap icon for the icon window.  I will
> eventually get around to fixing that.
> 
> I guess no post-2000 window manager even displays icon windows any more.
> 
> As for why it works for Jonas, I'm not sure.  Maybe his window manager
> somehow convinced Emacs to redisplay the title bar.

I think we've said about this issue everything that can be said.  So
I've now installed the change which allows icon-title-format to be t
(but leaving the default as it was), and updated the documentation
accordingly.  (While at that, I've also found and fixed some
inaccuracies in description of the effects of the 'title' and 'name'
frame parameters and their effect on the frame's title.)

With that, I'm closing this bug.

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

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> >   . 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.

I don't object to use `t' instead of `nil'. I object to leaving the
default as is.

>> > 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.

You already have a real case of a broken setup (mine). Furthermore, the
people that depend on the contents of the window title to automate
things on their machines are the most likely to set frame-title-format,
and thus it is practically guaranteed that having a working
icon-title-format on its current incarnation will be problematic for
them.

>> 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,

icon-title-format already broke my customization, and I already fixed it
on my .emacs.el. This is not about me, it is about avoiding the pain I
went through to others.

> 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.

This is about a real group of users for which this issue can cause lots
of disruption and frustration (Emacs' window title switching to the
contents of icon-title-format when the user jumps to other virtual
desktop is far from obvious) vs an hypothetical group of users that
somehow put on their config an effectless variable on a way that causes
the interpreter to throw an error on their face.

For which group do you expect more bug reports?