[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 23.0.50; utf7-decode failed with non latin-1 charactor
From: |
Kenichi Handa |
Subject: |
Re: 23.0.50; utf7-decode failed with non latin-1 charactor |
Date: |
Wed, 07 Nov 2007 21:51:16 +0900 |
User-agent: |
SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/23.0.60 (i686-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) |
In article <address@hidden>, Jason Rumney <address@hidden> writes:
> Kenichi Handa wrote:
> > It seems that fucntions utf-7-decode and utf-7-encode are
> > designed to be called only as pre-write/post-read functions
> > of a coding system utf-7 (and commented out coding system
> > utf-7-imap) in lisp/international/utf-7.el.
> >
> Is it a requirement for such functions to return nil?
> If not, can we return the encoded string instead of nil,
utf-7-encode is called from pre-write functions
utf-7-pre-write-conversion and
utf-7-imap-pre-write-conversion, and they expects
utf-7-encode to put the encoded result in a new buffer.
So, it's possible to make utf-7-encode return a string, but
it's inefficient to make a string that is just ignored when
callled from utf-7-pre-write-conversion.
> to make the
> undocumented string FROM argument useful (as a drop in replacement for
> the gnus utf7-encode).
Why is that necessary? We can use encode-coding-string.
I want to keep the entry points for encoding and decoding
only to the functions decode/encode-coding-region/string.
---
Kenichi Handa
address@hidden