unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "Óscar Fuentes" <ofv@wanadoo.es>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 61496@debbugs.gnu.org
Subject: bug#61496: 30.0.50; Default value of icon-title-format
Date: Tue, 14 Feb 2023 14:35:56 +0100	[thread overview]
Message-ID: <87mt5gqshv.fsf@telefonica.net> (raw)
In-Reply-To: <83fsb8e8yr.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 14 Feb 2023 14:18:36 +0200")

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.





  reply	other threads:[~2023-02-14 13:35 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-14  0:02 bug#61496: 30.0.50; Default value of icon-title-format Óscar Fuentes
2023-02-14  9:20 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-14 12:18 ` Eli Zaretskii
2023-02-14 13:35   ` Óscar Fuentes [this message]
2023-02-14 14:13     ` Eli Zaretskii
2023-02-14 14:32       ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-14 14:42         ` Eli Zaretskii
2023-02-14 14:57           ` Óscar Fuentes
2023-02-14 17:29             ` Eli Zaretskii
     [not found]               ` <87o7pto9zb.fsf@bernoul.li>
2023-02-16 16:44                 ` Eli Zaretskii
2023-02-16 17:09                 ` Eli Zaretskii
2023-02-17  1:10                   ` Óscar Fuentes
2023-02-17  2:47                     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-17  7:46                       ` Eli Zaretskii
2023-02-14 14:50       ` Óscar Fuentes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87mt5gqshv.fsf@telefonica.net \
    --to=ofv@wanadoo.es \
    --cc=61496@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).