<<< Date Index >>>     <<< Thread Index >>>

Re: Bug#414828: mutt inserts attribution in wrong charset



On Monday, March 26 at 05:26 PM, quoth Christoph Berg:
It seems we have 3 different locales:
1) the system's/LANG/LC_* 2) $locale 3) C

3 can probably be treated as 1. The main use for 2 on systems supporting LANG/LC_* seems to be able to use language-specific dates in attributions.

Should it then perhaps be renamed to $date_locale, just for more clarity?

    I can imagine 2 ways to do it:

 -a) Initialise $locale to current locale.

-b) Initialise $locale to "", and make this get the current locale (instead of skipping setlocale()).

(b) would have the advantage to follow runtime environment changes (for those using the setenv patch). I'd vote for that.

I'm not sure what the technical difference here is. "" (unset) seems to have the advantage that "if unset, $LANG will be used" is a bit more concise than "this variable is initialized to $LANG on mutt startup". (Modulo environment changes, the effect is probably the same.)

I think the idea is that option B fetches the locale from the environment every time $locale is needed, thus if you change LC_TIME (say, with the setenv patch) it will reflect the change without needing to change $locale.

OTOH, it seems that if you're going to use an extra patch like that, your expectation of having it "magically" work with the rest of mutt is pretty low; and doing a getlocale() every time for people who *aren't* using a nonstandard patch seems wasteful. Just my 2 cents.

Add ! everywhere to reget English by default? Humm... OK, today is only a first step, right? Anyway this would also break some existing muttrcs (those which set $locale and count on default $index_format to get localized time).

Do we *have* to stick to ignoring the locale and using English by default? Can't we say "NEW! One of the features of mutt 1.6 is more thorough support of locales!" and just tell people "learn to enjoy telling mutt what you want rather than having it try to read your mind"?

I'm more concerned about the defaults for users not having a muttrc. Those who have one will probably already have tweaked there *_format variables to the right thing.

Should we really be worried about users who don't care enough to have a muttrc being surprised when mutt adapts itself more fully to their environment? I mean, if I have refused to configure software to my liking, I fully expect that it could change its defaults on me. That's why my vimrc (for example) contains a lot of the things that are often set by default. (That, and because sometimes the defaults are changed in the system-wide vimrc, and I like having my vim behave the same on every computer.)

On a broader scale, on which kinds of systems do we really need $charset and $locale inside mutt? Can't we just expect them to set LC_*? If so, we could modify $locale such that it is only used for sending mail and leave other localization (mainly dates displayed in the index) at the current locale. $charset could probably be dropped completely.

I always thought $charset was a bit redundant anyway, but I assumed it was for weird and/or old systems that didn't have proper LC_* support.

~Kyle
--
I love America more than any other country in this world, and, exactly for this reason, I insist on the right to criticize her perpetually.
                               -- James Baldwin, Notes of a Native Son

Attachment: pgpgIB6g7205w.pgp
Description: PGP signature