time to fix known FLIM/APEL/SEMI problems

[Kazuhiro Ito]

Hi.

> Also I see almost 2-years old attempt to fix a problem with corrupted
> attaches saved on the disk (bug in mel-b-ccl):
> http://news.gmane.org/group/gmane.emacs.mime.japanese/thread=669/force_load=t

FLIM (mel-q-ccl, not mel-b-ccl) defines a coding system for
encoding/decoding quoted-printable with make-ccl-coding-system() which
is provided by APEL.  make-ccl-coding-system() defines LF EOL-type
coding system on Emacs 20, but it defines undecided EOL-type (and
additional other EOL-type) on Emacs 21 and later.  FLIM assumes Emacs
20's behaviour and additionally defined CRLF EOL-type coding system
fails to decode.  Emacs 22 and later on Windows select CRLF EOL-type
for writing operation in undecided EOL-type coding system and fail to
decode.

Possible solutions are below.

(1) Make make-ccl-coding-system() to always define only LF EOL-type
coding system.
(2) Make make-ccl-coding-system() to accept optional argument and to
be enabled to define LF EOL-type coding system explicitly, and make
FLIM to define LF EOL-type coding system.
(3) Make FLIM to define functional coding system with whichever EOL-type.
(4) Make FLIM to use LF EOL-type coding system explicitly. 

My first patch takes (4), but I think it is ad hoc.  Second patch
takes (1).  MORIOKA Tomohiko (maintainer of APEL) said he feeled (2)
was better.


> I can't read this thread in japaneese, translate.google.com also gives
> up. Can anybody confirm that author didn't write about new problems
> with that patch?

I don't write any more about that problem except this message. 

-- 
Kazuhiro Ito