> LCL internal encoding is not the same thing as source code encoding
> which is not the same things as arbitrary text data used by your
> application.
> 
Of course. There are:
1. LCL internal encoding (encoding of LCL sources), 
2. Lazarus IDE internal encoding, 
3. encoding of .po files, 
4. SynEdit internal encoding, 
5. special project files encoding (.lpi, .lrs and, may be in some cases, lfm) 
6. current source encoding, 
7. importing project encoding.
8. other files encoding

While 2 and 4 can use any encoding which is convenient for Lazarus developers, 
3 and 5 should be unified (utf8 is not a bad choice), 1 should be 
encoding-invariant (ASCII7), but 6 and 7 are the choice of user-programmer, and 
8 is a problem of user-programmer who tries to read it. Presently both 6 and 7 
are forced either as a system encoding on Windows (or fake system in Win2k+) or 
UTF-8 on gtk2. Is it so good? I think, forcing anyone to use anything is a bad 
idea. Especially it is bad for 7, when it is known that utf8 is not used. 

> Just because you are using source code encoded at utf-8 this doesn't
> mean your application needs to read text data from users encoded on
> utf-8 too.
It is obvious. But... Pascal files were considered as a text files, but now 
they can't be considered such anymore. As for me, UTF-8 file is not a text 
file, it is just an abrakadabra with many hard sings (who don't know - hard 
sing is the most rare letter in Russian, and in now most popular Russian 
encoding cp1251 - its popularity is other bad story, but it is a fact - it is 
#255) and for many others it is right too.
> 
> Of course, if the data is not in utf-8 you need to convert it if you
> plan on passing it to LCL, but there are plenty of routines to do this
> task, such as Utf8Encode, Utf8Decode, Utf8ToAnsi, AnsiToUtf8, etc.
Yes, but to use anything else including clean FPC you should return to original 
encoding. Besides, try to use Writeln('.........');
in current encoding, which is not UTF8. Windows had such problem from the 
beginning (requires AnsiToOEM), but why should we introduce the same problem 
(and double it for Windows) in Unix?
Yes, there are some means to live with UTF8, but why should anyone to live with 
it when he can live without it? Or just live with it and doesn't notice any 
changes? And it is only while he wants to live without it! This should be an 
option to use either system encoding or to use utf8.

_________________________________________________________________
     To unsubscribe: mail [EMAIL PROTECTED] with
                "unsubscribe" as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

Reply via email to