Re: tlug: Mutt-J question

[Frank Bennett <bennett@example.com>]

Hmm.  Acting on Steve Turnbull's intuition (quoted below), I did a "grep
2022" of the Mutt sources.  The result, also given below, suggests that
for Mutt, only "iso-2022-jp" will do.  See my poke-in-the-dark comments
below.

On Fri, Feb 05, 1999 at 05:45:03PM +0900, Stephen J. Turnbull wrote:

>   Content-Type: text/plain;  charset=csiso2022jp
> 
> This is a legal alias for ISO-2022-JP.  I don't have my IANA URL
> handy, but I'm sure it's not the preferred MIME form.  Dweebs.
> 
> Only a Mutt internals expert would know, but I bet Mutt does not have
> a complete internal table of all registered charset names.  Check to
> see if the 0x1B characters you think you are seeing on screen aren't
> really "^[" (two ASCII characters).  My bet is that Mutt displays all
> ASCII characters and attempting to do something "reasonable" with
> non-ASCII characters when you have filtering on and it has no method
> for interpretation of the MIME-specified charset.  When you go to full
> headers, I bet you also get raw text, and kterm "magically" interprets
> the escape sequences and displays Japanese.

Here's the result of grep 2022 * in the top level of Mutt sources:

handler.c:        if (strncasecmp ("iso-2022-jp", charset, 11) == 0 &&
handler.c:        if (!option (OPTWEED) || !charset || strncasecmp
("iso-2022-jp", charset, strlen ("iso-2022-jp")) == 0)
init.h:  { "charset",           DT_STR,  R_NONE, UL &Charset, UL
"iso-2022-jp" },
khenkan.c:/* only for ISO-2022-JP */
mutt.h:#define CH_KDECODE       (1<<12) /* decode iso-2022-jp */
mutt.h:  unsigned int iso2022jp : 1;    /* has iso2022jp text */
sample.muttrc-for-japanese:set charset="iso-2022-jp"
sendlib.c:          info->iso2022jp = 1;
sendlib.c:          info->iso2022jp = 1;
sendlib.c:  else if (info->iso2022jp)
sendlib.c:    return ("iso-2022-jp");
sendlib.c:  return (Charset[0] ? Charset : "iso-2022-jp");

Sendlib sets up to send a message, so that looks to be irrelevant.  Init
must initalize, and mutt.h and khenkan.c only have the proper MIME string
in a comment.  Which leaves handler.c, which appears to be used for
parsing the MIME type of incoming messages.  The context of the occurrence
of iso-2022-jp there is:

#ifdef KANJI
       {
          char *charset = mutt_get_parameter ("charset", b->parameter);
          if (strncasecmp ("iso-2022-jp", charset, 11) == 0 &&
              !option (OPTWEED)) {
            plaintext = 1;
          }
          else
#endif

So it looks like if I hack in an additional test for the MIME string that
is failing for me, things might work okay.  I'll give it a go when I've
got the time.  Not a proper fix, though.

Cheers,
-- 
-x80
Frank G Bennett, Jr         @@
Faculty of Law, Nagoya Univ () email: bennett@example.com
Tel: +81[(0)52]789-2239     () WWW:   http://rumple.soas.ac.uk/~bennett/

-------------------------------------------------------------------
Next Technical Meeting: February 13 (Sat), 12:30 place: Temple Univ.
** presentation: XEmacs, by Steven Baur and Martin Buchholz
Next Nomikai: March 19 (Fri), 19:30   Tengu TokyoEkiMae 03-3275-3691
-------------------------------------------------------------------
more info: http://tlug.linux.or.jp                     Sponsor: PHT