--- Begin Message ---
|
Subject: |
30.0.50; Default value of icon-title-format |
|
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.
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#61496: 30.0.50; Default value of icon-title-format |
|
Date: |
Fri, 17 Feb 2023 09:46:07 +0200 |
> 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.
--- End Message ---