all messages for Emacs-related lists mirrored at yhetil.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

* 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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.