Stephen J. Turnbull wrote:
Aidan Kehoe writes:
> Reliably differentiating those [bit-for-bit identical] pairs
> without metadata is not possible.
And unnecessary, precisely because it's not possible. It's only when
you add disambiguating text that it matters, and then the Sufficiently
Smart Program argument applies.
I hate to disturb your conversation -- but I want to add the voice
of one European (German) user: Aidan expresses the problem, and you
seem to reject work on it to get a Really Good Design. But it ain't
so easy, from this user's perspective -- sometimes Worse Is Better,
as we all have learned from Dick Gabriel.
It is highly annoying that I need to explicitly, manually, specify
the buffer-coding-system for a file when I want to insert an EUR
sign and when I want it to end up encoded in ISO-8859-15. And
that's the current state of affairs, AFAICS.
Since many of us use templates for new files anyhow, it's a small
matter to add an appropriate cookie to demand a specific encoding
for a file. That this approach is effectively rejected by you, is
really disturbing for us European users. Maybe one doesn't need it
for Japanese scripts and for UTF-8, but for us poor souls who still
want to use ISO-8859-* for other reasons, it would be a real advantage.
Well, speaking of UTF-8: Since XEmacs is very happy to destroy lots
of my files with its supposedly smart encoding detection -- and
does so WITHOUT any warning -- your demand for more thought about
error recovery is right on spot. But there seems to be other areas
that are in more severe need of that error handling than recovery
from wrong coding cookies (namely, automatic encoding sniffing). I
have had literally dozens of UTF-8 files with one single Latin1
char in them, that got reencoded by XEmacs when I opened and saved
them. (I.e., when I didn't pay enough attention to the modeline in
the process of quickly modifying one or two words.) In all these
cases, reliance on a user-supplied coding cookie would have saved
me untold hours and hours of work to redo the result of XEmacs
automatic encoding detection which Really Really Really Sucks.
Throwing an error if the coding system is not sufficient is much
preferred to the current state of affairs (arbitrarily choosing a
coding system that XEmacs thinks is right).
Sorry about sounding frustrated -- but I am, and your insistence on
Sufficiently Smart Programs(tm) being the Right Way(tm) does not
match my experience with XEmacs, or with programs at all. Please
let us have our way to specify "yes, I want the buffer of this file
in THIS coding system and be DAMNED if you try to switch on another
one beneath my back. I know what I'm doing because I'M THE USER and
I'M ALWAYS RIGHT BY DEFINITION because I know more about MY OWN
FILES than you bloody stupid detection algorithm."
Please.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Joachim Schrod Email: jschrod(a)acm.org
Roedermark, Germany
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta