emacs-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]