From tomo ＠ m17n.org  Sat Sep  6 23:58:56 2008
From: tomo ＠ m17n.org (=?ISO-2022-JP?B?GyRCPGkyLBsoQg==?=
 =?ISO-2022-JP?B?GyRCQ05JJxsoQg==?= / MORIOKA Tomohiko)
Date: 06 Sep 2008 23:58:56 +0900
Subject: make-ccl-coding-system =?ISO-2022-JP?B?GyRCJE4bKEI=?=
	=?ISO-2022-JP?B?GyRCISIlUCE8JTglZyVzME1COCRORjA6biRLGyhC?=
	=?ISO-2022-JP?B?GyRCJEQkJCRGGyhC?= (Re:
 Quoted-Printable =?ISO-2022-JP?B?GyRCJEolKCVzJUYlIyVGGyhC?=
	=?ISO-2022-JP?B?GyRCJSMkTkpdQjgkSzw6R1QkOSRrGyhC?=
	=?ISO-2022-JP?B?KQ==?=
In-Reply-To: Kazuhiro Ito's message of "Fri, 08 Feb 2008 23:49:26 +0900"
References: <u8x4ik2z9.wl%kzhr@d1.dion.ne.jp>
 <uzlubijux.wl%kzhr@d1.dion.ne.jp>
Message-ID: <htx7i9pcocv.fsf@urania.kanji.zinbun.kyoto-u.ac.jp>

>>>>> [apel-ja : No.01450] にて
>>>>> Kazuhiro Ito <kzhr ＠ d1.dion.ne.jp> さま曰く:

> さて、この mel-ccl-quoted-printable-lf-lf-rev という coding system は
> APEL で提供される make-ccl-coding-system を用いて作られています。
> 
> ところが、make-ccl-coding-system を用いて coding system を作った場合、
> Emacs 21以降とそれより前では動作が異なります。
> (以下はソースからの推測もまじります。
>  Meadow (Emacs 20.7.1) と Meadow2 (Emacs 21.4.1) 以降で異なる事は
>  確認しました。)
> Emacs 20.7 までは EOL type が LF に設定されますが、
> Emacs 21.1 以降 では EOL type が undecided に設定され、
> -unix, -dos, -mac が末尾についた coding system も同時に作成されます。
> 
> これは、make-ccl-coding-system から呼び出される make-coding-system の
> 動作が変わった事によります。
> Emacs 21 以降の make-coding-system は、オプションの引数 eol-type が
> 増え、指定しない場合は EOL type が undecided な coding system を
> 作成するようになりました。
> Emacs 20.7 以前は CCL based な coding system の場合、常に EOL type は
> LF になっていたようです。
> 
> 取り敢えず Emacs 21 以降でも EOL type が LF な coding system のみが
> 作られるようにするパッチを添付します。
> APEL の仕様が分からないので FLIM とどちらで対策すべきかも
> 分かりませんが、仕様と対策をご検討いただければ幸いです。

伊藤さま、御報告ありがとうございます。

APEL としてはどうすべきか悩ましいのですが、個人的には Emacs 21.1 以降
の仕様に合わせるのが良いような気がします。

・APEL としては、関数 make-ccl-coding-system にオプショナル引数 
  EOL-TYPEを追加する

・FLIM では EOL-TYPE として 'unix を指定する（本当は、Emacs 21.1 以降
  用に CRLF と LF の変換用コードを削ったものを用意しちゃえば良いかも知
  れませんが）

というのではいかがでしょうか？

-- 
┯━…‥・懐かしい未来の記憶をふと思い出しかけた・‥…━━┯━━━┯━
││ ─ │  ─  ／    ─   ┼─     ┬                ─   ─┼ ┬┴─
┼┼─┼|〓━─┼ 守岡 知彦 (MORIOKA Tomohiko) <tomo ＠ m17n.org> ─ ─┬
┻┻━┻━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━━━




From kzhr ＠ d1.dion.ne.jp  Mon Sep  8 16:01:54 2008
From: kzhr ＠ d1.dion.ne.jp (Kazuhiro Ito)
Date: Mon, 08 Sep 2008 16:01:54 +0900
Subject: make-ccl-coding-system =?ISO-2022-JP?B?GyRCJE4bKEI=?=
	=?ISO-2022-JP?B?GyRCISIlUCE8JTglZyVzME1COCRORjA6biRLGyhC?=
	=?ISO-2022-JP?B?GyRCJEQkJCRGGyhC?= (Re:
 Quoted-Printable =?ISO-2022-JP?B?GyRCJEolKCVzJUYlIyVGGyhC?=
	=?ISO-2022-JP?B?GyRCJSMkTkpdQjgkSzw6R1QkOSRrGyhC?=
	=?ISO-2022-JP?B?KQ==?=
In-Reply-To: <htx7i9pcocv.fsf@urania.kanji.zinbun.kyoto-u.ac.jp>
References: <u8x4ik2z9.wl%kzhr@d1.dion.ne.jp>	<uzlubijux.wl%kzhr@d1.dion.ne.jp>	<htx7i9pcocv.fsf@urania.kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <uiqt786jh.wl%kzhr@d1.dion.ne.jp>

伊藤です。

ご検討ありがとうございます。

> ・APEL としては、関数 make-ccl-coding-system にオプショナル引数 
>   EOL-TYPEを追加する
> ・FLIM では EOL-TYPE として 'unix を指定する（本当は、Emacs 21.1 以降
>   用に CRLF と LF の変換用コードを削ったものを用意しちゃえば良いかも知
>   れませんが）
> というのではいかがでしょうか？

私自身は単なる Wanderlust ユーザですので、基本的には仕様がはっきりして
バグが取れれば何でもいいと思っています。
APEL を変更するとすれば、 eol-type を指定できるようにするか eol-type を
常に LF にするかだと思っていたので、特に反対する要素はありません。

-- 
伊藤 和博(Kazuhiro Ito)




From yoichi ＠ geiin.org  Sat Sep 13 11:28:58 2008
From: yoichi ＠ geiin.org (Yoichi NAKAYAMA)
Date: Sat, 13 Sep 2008 11:28:58 +0900
Subject: =?ISO-2022-JP?B?GyRCSVRANSRKGyhCcXVvdGVkLXByaW50?=
	=?ISO-2022-JP?B?YWJsZQ==?= =?ISO-2022-JP?B?IGRhdGE=?=
	=?ISO-2022-JP?B?GyRCJE4wNyQkJEskRCQkJEYbKEI=?=
Message-ID: <86k5dg6aol.wl%yoichi@geiin.org>

なかやまです。
Redmineの出すメールのSubjectが mel-q-ccl.elではデコード
出来ず、mel-q.elではデコードできたので調べてみたのですが、
当該メールでは "=?utf-8?Q?=5b?=" のように小文字で入っている
のが問題でした。

mel-q.elのquoted-printable-hex-char-to-numでは[a-f]を10-15に
マップしていますが、mel-ccl-256-to-16-tableではそれらをnilに
マップしている為に問題が生じていました。

RFC2045によればエンコードの際は大文字でなければならないとされて
いますが、デコードについては
    (1)   An "=" followed by two hexadecimal digits, one or both
          of which are lowercase letters in "abcdef", is formally
          illegal. A robust implementation might choose to
          recognize them as the corresponding uppercase letters.
と書いてあるのでmel-q.elのような緩い実装もありだと解釈して
います。mel-qとmel-q-cclで挙動が違うのはわかりにくいので
緩い方に合わせてしまうのはいかがでしょうか？

もしそうする場合、mel-ccl-256-to-16-table を単純に変更して
しまっても問題ないでしょうか？

以上、よろしくお願いします。
-- 
Yoichi NAKAYAMA




From yoichi ＠ geiin.org  Wed Sep 17 12:50:20 2008
From: yoichi ＠ geiin.org (Yoichi NAKAYAMA)
Date: Wed, 17 Sep 2008 12:50:20 +0900
Subject: =?ISO-2022-JP?B?GyRCSVRANSRKGyhCcXVvdGVkLXA=?=
	=?ISO-2022-JP?B?cmludGFibGU=?= =?ISO-2022-JP?B?IGRhdGE=?=
	=?ISO-2022-JP?B?GyRCJE4wNyQkJEskRCQkJEYbKEI=?=
In-Reply-To: <86k5dg6aol.wl%yoichi@geiin.org>
References: <86k5dg6aol.wl%yoichi@geiin.org>
Message-ID: <86d4j35t37.wl%yoichi@geiin.org>

なかやまです。

At Sat, 13 Sep 2008 11:28:58 +0900,
Yoichi NAKAYAMA wrote:
> Redmineの出すメールのSubjectが mel-q-ccl.elではデコード
> 出来ず、mel-q.elではデコードできたので調べてみたのですが、
> 当該メールでは "=?utf-8?Q?=5b?=" のように小文字で入っている
> のが問題でした。
> 
> mel-q.elのquoted-printable-hex-char-to-numでは[a-f]を10-15に
> マップしていますが、mel-ccl-256-to-16-tableではそれらをnilに
> マップしている為に問題が生じていました。
> 
> RFC2045によればエンコードの際は大文字でなければならないとされて
> いますが、デコードについては
>     (1)   An "=" followed by two hexadecimal digits, one or both
>           of which are lowercase letters in "abcdef", is formally
>           illegal. A robust implementation might choose to
>           recognize them as the corresponding uppercase letters.
> と書いてあるのでmel-q.elのような緩い実装もありだと解釈して
> います。mel-qとmel-q-cclで挙動が違うのはわかりにくいので
> 緩い方に合わせてしまうのはいかがでしょうか？
> 
> もしそうする場合、mel-ccl-256-to-16-table を単純に変更して
> しまっても問題ないでしょうか？

差分を添付します。問題あればご指摘おねがいします。
-- 
Yoichi NAKAYAMA
-------------- next part --------------
テキスト形式以外の添付ファイルを保管しました...
ファイル名: qp.diff
型:         application/octet-stream
サイズ:     1432 バイト
説明:       無し
URL:        <http://lists.chise.org/pipermail/emacs-mime-ja/attachments/20080917/3dc512d5/attachment.obj>

From yoichi ＠ geiin.org  Sat Sep 20 22:12:19 2008
From: yoichi ＠ geiin.org (Yoichi NAKAYAMA)
Date: Sat, 20 Sep 2008 22:12:19 +0900
Subject: =?ISO-2022-JP?B?GyRCSVRANSRKGyhCcXVvdGVkLXA=?=
	=?ISO-2022-JP?B?cmludGFibGU=?= =?ISO-2022-JP?B?IGRhdGE=?=
	=?ISO-2022-JP?B?GyRCJE4wNyQkJEskRCQkJEYbKEI=?=
In-Reply-To: <86d4j35t37.wl%yoichi@geiin.org>
References: <86k5dg6aol.wl%yoichi@geiin.org>
	<86d4j35t37.wl%yoichi@geiin.org>
Message-ID: <868wtn55cc.wl%yoichi@geiin.org>

At Wed, 17 Sep 2008 12:50:20 +0900,
Yoichi NAKAYAMA wrote:
> At Sat, 13 Sep 2008 11:28:58 +0900,
> Yoichi NAKAYAMA wrote:
> > Redmineの出すメールのSubjectが mel-q-ccl.elではデコード
> > 出来ず、mel-q.elではデコードできたので調べてみたのですが、
> > 当該メールでは "=?utf-8?Q?=5b?=" のように小文字で入っている
> > のが問題でした。
> > 
> > mel-q.elのquoted-printable-hex-char-to-numでは[a-f]を10-15に
> > マップしていますが、mel-ccl-256-to-16-tableではそれらをnilに
> > マップしている為に問題が生じていました。
> > 
> > RFC2045によればエンコードの際は大文字でなければならないとされて
> > いますが、デコードについては
> >     (1)   An "=" followed by two hexadecimal digits, one or both
> >           of which are lowercase letters in "abcdef", is formally
> >           illegal. A robust implementation might choose to
> >           recognize them as the corresponding uppercase letters.
> > と書いてあるのでmel-q.elのような緩い実装もありだと解釈して
> > います。mel-qとmel-q-cclで挙動が違うのはわかりにくいので
> > 緩い方に合わせてしまうのはいかがでしょうか？
> > 
> > もしそうする場合、mel-ccl-256-to-16-table を単純に変更して
> > しまっても問題ないでしょうか？
> 
> 差分を添付します。問題あればご指摘おねがいします。

flim-1_14 に commit しました。
よろしくお願いします。
-- 
Yoichi NAKAYAMA