I don't suggest that anyone lock users out from anything. I suggest that
a converter that handles 40-some encodings—and I've written them
myself—is no longer one of "the most basic converters."
One advantage to the BabelPad approach, which I guess sort of fits
Postel's robustness principle, is that it takes the burden away from the
editor to substitute for characters not supported by the target
encoding.
--
Doug Ewell | Thornton, Colorado, USA
http://www.ewellic.org | @DougEwell
-----Original Message-----
From: Asmus Freytag
Sent: Thursday, October 18, 2012 5:46
To: Doug Ewell
Cc: [email protected] ; Stephan Stiller ; [email protected]
Subject: Re: texteditors that can process and save in different
encodings
How does the old saying go "Be liberal in what you accept, be
conservative in what you emit".
In that sense, there's a place for a much wider array of input
encodings, coupled with a gentle insistence on not letting the user save
things in outdated formats.
In terms of which input sets are "basic", that should depend on how
likely the input is in that format. Whether you pick the top ten, top 5
or top 3 is a matter of choice, but I wouldn't confuse "basic" with
"recommended".
Locking users out from content isn't smart - helping them to migrate
data is.
A./
On 10/17/2012 10:03 PM, Doug Ewell wrote:
Step by step, this started with "the most basic converters" and has
evolved into something much more extensive. The .NET framework
supports dozens of non-Unicode encodings. Once you go down this path,
users will reasonably expect your app to provide all kinds of
character processing, like CRLF conversion and \Uxxxx conversion and
trailing-space stripping and tab/space conversion and maybe
normalization. This is the situation we are in today.
