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

Re: INSTALL doesn't conform to howmutt behaves



Hello Karel,

 On Thursday, June 24, 2004 at 9:56:36 AM +0000, Karel Kulhavy wrote:

> During compilation the LOCALES_HACK has been disabled: -LOCALES_HACK

    That's good: --enable-locales-fix should be reserved for broken
systems where it's just plain impossible to do otherwise.


>| $ echo ">$LANG<=$LC_ALL=|$LC_CTYPE|"
>| ><==||

    BTW this echo doesn't tell if vars are really unset, or set to empty
string. Empty string could give sometimes random behaviour depending on
circumstances. </BTW>


> INSTALL says:
>| Mutt will attempt to use isprint() if either of the environment
>| variables LANG, LC_ALL or LC_CTYPE is set, and will revert to the
>| ISO-8859-* range if they aren't.
> reply to address "Michal Mal\371\271ek <m.malusek@xxxxxxxxx>" I get
> this: To: Michal@xxxxxxxxxxxxxxxxxx, Mal@xxxxxxxxxxxxxxxxxx
> [...] mutt assumes characters \371 and \271 are not printable

    Yes, partly. The "novars" workaround works sometimes OK, like when
displaying body of mails, or replying on -HAVE_WC_FUNCS systems. And
fails sometimes, like your reply case. This makes "novars" unsure, and
so mostly useless.


    Last time this was discussed, one considered that this novars thing
was a workaround not worth to be corrected, because dirty, limited to
some charsets, and that setting a correct locale is *the* good solution.

    OTOH novars works partly, is beginners friendly, exists already in
code, is documented, and there should not be impossible to correct it
where it fails.

    So far clear choice not done: Remove novars from code and INSTALL,
fix novars failures, or do nothing.


Bye!    Alain.
-- 
Software should be written to deal with every conceivable error
        RFC 1122 / Robustness Principle