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

Re: introduction / first question and special characters



Hi Daniel,

 On Tuesday, September 20, 2005 at 11:19:12 PM +0200, Daniel Hertrich wrote:

> On 20:58 Wed 14 Sep     , Alain Bench wrote:
                      ^^^^
    Where is the year? Strange: You're not the first one to have 4
spaces there... What happens with default $attribution/$date_format?


    [checklocale.c]
>   LANG        = "de_DE.ISO-8859-1"
> - Implicitly setting all locale categories with LANG failed.

    It was expected to fail: Set straight like that, the
de_DE.ISO-8859-1 data directory has to be in the default locale place.
And we don't know this place for sure (/usr/lib/locale/?). You could try
LANG="../../../tmp/de_DE" with varying ../ levels until checklocale
eventually succeeds? With locales-de.tar.gz detared in /tmp of course.


>   LANG        = "C"
> - Implicitly setting all locale categories with LANG succeeded.

    The printability table has a "#" for each character considered
unprintable. The US-Ascii charset has no character after 127.


> I have asked in the Zaurus forums for locale issues and solutions.
> Hopefully someone will give a good hint.

    I'll Google for it, but please make us a summary (or link) here.


> Can I consult the INSTALL of any available source package of libiconv
> or are there differences?

    I don't know, but hopefully no differences. Though make sure to take
the corresponding version 1.8 source tarball at
<URL:http://ftp.gnu.org/pub/gnu/libiconv/libiconv-1.8.tar.gz>.


>> Describe and quote what you see here: ?? [was an UTF-8 ä (a umlaut)]
> with us-asii I see two question marks

    This means: Unconvertable from UTF-8 to US-Ascii character. Mutt
masks each such *byte* with a question mark.

> with ISO-8859-1 I see "backslash 3 4 4"

    This means: Convertable, converted from UTF-8 to Latin-1 for
display, but then considered unprintable.

    This validates your iconv setup works OK, now that libiconv is
renamed out. Only the locale is still broken. And Mutt build with
workarounding options also.


>> export set TERM=linux
> "set" is superfluous you mean?

    Exactly. Worse: It would actually export a variable named "set" if
you had one.


>> Your subscribe regexps are too lax.
> How should they look like?

    At best, they should be the strictest possible. Example:

| subscribe ^mutt-users@mutt\\.org$


>> $send_charset is broken, perhaps by HTMLization.
> rechecked on the web page... what is wrong with the send_charset?

    Hum... It *was* wrong, with spurious chars inside value. But now
it's OK. More oddly, the page content and date are not the same when
viewed online, and later when viewed from cache offline. I now see
offline a _broken_ version exported on September 2.


> I thought about another possible workaround for the Umlaut problem: I
> could probably let all mails pass a filter which converts the Umlauts
> to something like ae, oe, ue etc.

    Let magic iconv transliteration do that on-the-fly without hazardous
munging of the original mailbox. Set $charset="us-ascii//TRANSLIT". Note
in such workaround setup, you're not supposed to send umlauts...


    BTW your Slrn/Mutt interaction problem truncating recipient name is
also due to broken locale.


Bye!    Alain.
-- 
set honor_followup_to=yes in muttrc is the default value, and makes your
list replies go where the original author wanted them to go: Only to the
list, or with a private copy.