help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Impossible to customize world clock


From: Eli Zaretskii
Subject: Re: Impossible to customize world clock
Date: Tue, 09 Apr 2024 21:34:04 +0300

> Date: Tue, 09 Apr 2024 12:52:21 -0400
> From:  Stefan Monnier via Users list for the GNU Emacs text editor 
> <help-gnu-emacs@gnu.org>
> 
> > Then maybe I'm missing something because I don't understand how would
> > that help the OP.  He said:
> >
> >> I add a new one (Europe/Berlin):
> >> 
> >>   '(zoneinfo-style-world-list
> >>     '(("America/Los_Angeles" "Seattle")
> >>       ("America/New_York" "New York")
> >>       ("Europe/London" "London")
> >>       ("Europe/Paris" "Paris")
> >>       ("Asia/Calcutta" "Bangalore")
> >>       ("Asia/Tokyo" "Tokyo")
> >>       ("Europe/Berlin" "Germany"))))
> >
> > How would your suggestion help him to "add Europe/Berlin"?
> 
> When looking how to add Berlin, he'd search for the vars to change and
> would find `world-clock-list` with a list of elements of the form (NAME
> OTHERNAME FUNNYNAME), so it would (hopefully) naturally make him wonder
> which part to change.  In contrast with the current situation he
> stumbled upon `zoneinfo-world-clock-list` and was stumped because it
> made no difference although his change was "correct".

That's not what I meant.  What I meant was how would users know which
XXXnYYY string to use for FUNNYNAME that will have the effect of
showing the time in Berlin, like "Europe/Berlin" does?

> Maybe a first way to avoid the problem would be simply to put different
> places in the default value of `zoneinfo-world-clock-list` than in
> `legacy-world-clock-list`, so that it'd be more obvious which is the one
> currently in use.

The idea behind the current values was to produce (almost) the same
display on all systems with the default values.  Your suggestion will
necessarily cause bug reports of the "I see this display on GNU/Linux,
but that display on Windows" kind.

If the only issue is to make sure users know what to customize, we
could clarify that in the doc strings.  That'd probably be more
efficient and will not change the default behavior.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]