Re: 23.0.50; utf7-decode failed with non latin-1 charactor

[Kenichi Handa <handa@ni.aist.go.jp>]

In article <4731ABC9.4080604@gnu.org>, Jason Rumney <jasonr@gnu.org> 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
handa@ni.aist.go.jp