[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "no-conversion" coding system

From: Stephen J. Turnbull
Subject: Re: "no-conversion" coding system
Date: Tue, 15 Jul 2008 15:34:13 +0900

Eli Zaretskii writes:
 > > From: Stefan Monnier <address@hidden>
 > > Date: Wed, 09 Jul 2008 21:12:41 -0400
 > > Cc: address@hidden, address@hidden, address@hidden
 > > 
 > > Technically, that may be true.  But take a utf-8 text and open it with
 > > "no-conversion" and it won't look like the same text, so for some
 > > interpretation of "conversion", it has been converted.

Irrelevant.  You can achieve the same kind of confusion with `emacs
-font'. :-)

 > no-conversion doesn't mean that the text will _look_ the same, it
 > means the byte stream will be the same.

That's true as a definition, and incorrect as a matter of fact in
multibyte buffers.  Unless Emacs enforces "no-conversion is unibyte",
"no-conversion" should die, and split its estate between "raw-text"
(where newline conventions are meaningful) and "binary" (or
"raw-bytes") for non-text files.

 > > Its other name "binary" is a lot more unequivocal.
 > Only if you are a programmer who knows that binary files are usually
 > read with no conversions.  Otherwise, the name "binary" doesn't have
 > any useful mnemonic meaning in the context of transforming one text
 > encoding into another.

Binary isn't a text encoding, and therefore it's entirely appropriate
that it lack a mnemonic meaning in the context of text encoding.<wink>

In any case, only Emacs maintainers should ever need to care about
the representational transformations performed by coding systems, and
they all do know what binary means.  Everybody else just needs to know
the magic spell that turns mojibake into language; even if they did
know about representations, they can't do anything about it.  (I guess
that's not strictly so in Emacs, but it should be. ;-)

reply via email to

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