Re: Question about how to specify coding system chains: encoding or decoding persepctive?
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.