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. _______________________________________________ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel