Re: Question about how to specify coding system chains: encoding ordecoding persepctive?
thanks for cc'ing me; i'm too busy to check xemacs-beta much.
in fact, i just created a "convert-eol" coding system to handle just the eol
stuff and i'm about to rewrite the subsidiary stuff to create chains using it --
there was no other obvious way to impose "crlf" on another chain. i've now
completed the generalization of coding system end types [byte or char -> byte or
char], and decode/encode-coding-region will insert the right stuff to convert
between bytes and chars as necessary. now just to test it all :]
Stefan is right, we need formats, not operations. the more i work on this stuff
the more i realize the separation of decoding/encoding is bogus. we really just
need a converter, and a coding system is a pair of converters that oppose each
other. it makes less and less sense to talk about which one "encodes" and
which
one "decodes". i still haven't quite figured out though how the user
should
specify a conversion using formats.
Hrvoje Niksic wrote:
Ben Wing <ben(a)666.com> writes:
[...]
First, thanks a bunch for implementing the coding system chaining.
It's incredibly useful, not only from an "internals" stand-point, but
for building a useful Mule. Finally we'll be able to undo the
horridness that is foo-coding-system-unix and similar.
If memory serves me, in current XEmacs/Mule we "encode" internal text
into an external byte representation.
Encoding in the context of "gzip" means "turn a stream of bytes into
something that will later require a gzip decoder to read". The same
with base64, etc.
> unicode-to-multibyte; but that gets very confusing if you're
> specifying a decoding chain, since the operation will be
> multibyte-to-unicode but you'll still have to give the opposite
> name.
My question would be: why? Why would you have to specify the opposite
name? E.g. you could define something like `define-decoding-chain' to
define chain of "decoding" stuff, as well as `define-encoding-chain'
to work in the naming-"natural" direction.
When saving files, encoding is natural. When loading file, decoding
is natural. I don't see a way to decide on one of them being more
important or natural than the other.
>From the perspective of the end user who wants to load a gzipped
iso-8859-2 file, he will probably first want to "load" the file. So
from his perspective, decoding is what he encounters first and hence
probably more "natural". Stephen Turnbull argues much the same.