Re: Multi byte charset support vs. single byte

[Koblinger Egmont <egmont uhulinux hu>]

On Sun, Jul 24, 2005 at 04:20:45PM +0200, Leonard den Ottolander wrote:

Hi,

> I was wondering if when we will implement multi byte charset support we
> should still keep a compile option to build for (low memory) single byte
> systems, or even a runtime option to choose between the two modes, as
> the use of wchar_t's is relatively memory hungry.

Please see my earlier mail at:
http://mail.gnome.org/archives/mc-devel/2005-April/msg00029.html

there I discuss why I think this whole approach of wchar_t is completely
wrong for a file manager / file viewer / file editor.

The most important part is that "file" does not always mean "text". MC
should keep on working perfectly with out-of-locale filenames or file
contents (e.g. binary files), the editor should remain binary safe even for
out-of-locale characters etc... This cannot be implemented with the "think
in characters" philosophy suggested by the use of wchar_t's. MC should still
"think in pure single 8-bit bytes" and only group some of them together for
displaying purposes. This is the only way for the user to be able to delete
or rename a file with non-valid UTF-8 filename under an UTF-8 system etc.
Which is, I think, a pretty much required feature of any file manager...
Discussed in more details in the mail mentioned above.

On the other hand, wchar_t can perfectly be used to store the information:
"what character we want to be displayed in a cell of the terminal". But then
the growth caused by the char -> wchar_t change is negligible, it is not
worth it offering any compile time options to turn it off.



e.