From v.mayatskih ¡÷ gmail.com Sat Aug 1 06:58:05 2009 From: v.mayatskih ¡÷ gmail.com (Vitaly Mayatskikh) Date: Fri, 31 Jul 2009 23:58:05 +0200 Subject: time to fix known FLIM/APEL/SEMI problems Message-ID: <87my6kqzv6.wl%vmayatsk@redhat.com> Hi! Juergen Fuhrmann solved his 'invisible umlauts in Emacs-23' problem by this patch: http://osdir.com/ml/mail.wanderlust.general/2008-04/msg00007.html It works with Emacs-23 and doesn't break anything in Emacs-22. It is sad this patch is not yet in cvs. 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 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? If both patches won't cause regressions on my setup for a couple of days, I'm going to commit them them to FLIM and bump it's version number to 1.14.10. Hope, FLIM live maintainers, if any, won't kill me :) In case you know about other good patches related to FLIM, APEL, SEMI or Wanderlust, please, let me know. Thanks! -- wbr, Vitaly -- wbr, Vitaly From kzhr ¡÷ d1.dion.ne.jp Tue Aug 4 06:44:09 2009 From: kzhr ¡÷ d1.dion.ne.jp (Kazuhiro Ito) Date: Tue, 04 Aug 2009 06:44:09 +0900 Subject: time to fix known FLIM/APEL/SEMI problems In-Reply-To: <87my6kqzv6.wl%vmayatsk@redhat.com> References: <87my6kqzv6.wl%vmayatsk@redhat.com> Message-ID: <82ab2gvahi.wl%kzhr@d1.dion.ne.jp> 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 From v.mayatskih ¡÷ gmail.com Tue Aug 4 21:47:03 2009 From: v.mayatskih ¡÷ gmail.com (Vitaly Mayatskikh) Date: Tue, 04 Aug 2009 14:47:03 +0200 Subject: time to fix known FLIM/APEL/SEMI problems In-Reply-To: <82ab2gvahi.wl%kzhr@d1.dion.ne.jp> References: <87my6kqzv6.wl%vmayatsk@redhat.com> <82ab2gvahi.wl%kzhr@d1.dion.ne.jp> Message-ID: <873a873fw8.wl%vmayatsk@redhat.com> At Tue, 04 Aug 2009 06:44:09 +0900, Kazuhiro Ito wrote: > 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. So, may be we'll do that in 2nd way? > > 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. Ok, thanks -- wbr, Vitaly From kzhr ¡÷ d1.dion.ne.jp Wed Aug 5 19:33:25 2009 From: kzhr ¡÷ d1.dion.ne.jp (Kazuhiro Ito) Date: Wed, 05 Aug 2009 19:33:25 +0900 Subject: time to fix known FLIM/APEL/SEMI problems In-Reply-To: <873a873fw8.wl%vmayatsk@redhat.com> References: <87my6kqzv6.wl%vmayatsk@redhat.com> <82ab2gvahi.wl%kzhr@d1.dion.ne.jp> <873a873fw8.wl%vmayatsk@redhat.com> Message-ID: <82ab2er1my.wl%kzhr@d1.dion.ne.jp> Hi. > > 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. > > So, may be we'll do that in 2nd way? I think emacs' version incompatibilities should be hidden by APEL, so (1) and (2) are better than (3), (4). But I don't know which (1 or 2) is better. If you choice (2), new FLIM loses compatibility with present APEL. So, new APEL must be released before (or at a time) new FLIM is released. -- Kazuhiro Ito