Re: texteditors that can process and save in different encodings

From: Doug Ewell <>
Date: Thu, 18 Oct 2012 06:38:23 -0600

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

Doug Ewell | Thornton, Colorado, USA | @DougEwell ­
-----Original Message----- 
From: Asmus Freytag
Sent: Thursday, October 18, 2012 5:46
To: Doug Ewell
Cc: ; Stephan Stiller ;
Subject: Re: texteditors that can process and save in different 
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
Locking users out from content isn't smart - helping them to migrate
data is.
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.
Received on Thu Oct 18 2012 - 07:40:26 CDT

This archive was generated by hypermail 2.2.0 : Thu Oct 18 2012 - 07:40:28 CDT