Re: texteditors that can process and save in different encodings

From: Asmus Freytag <>
Date: Thu, 18 Oct 2012 04:46:57 -0700

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 - 06:51:46 CDT

This archive was generated by hypermail 2.2.0 : Thu Oct 18 2012 - 06:51:48 CDT