Re: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority)
On Wed, May 3, 2017 at 6:13 AM, Ondrej Pokorny via Lazaruswrote: > Not if you need pre-unicode Delphi support :) > > (Well, Marcos didn't specify what Delphi version he wants to target but he > stated "If Delphi sources don't use UTF8 [...]", which applies to > pre-unicode Delphi versions.) Yeah, sorry. I said that because I didn't know which encoding Delphi is using nowadays. But I would like to use only Delphi with Unicode support with "dot.unit.support". Marcos Douglas -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority)
On 2017-05-03 20:47, Juha Manninen via Lazarus wrote: > If you share and edit the sources between Delphi and Lazarus then you > cannot use the full Unicode. Quite comical considering that the FPC team always makes such a big fuss about "we want Delphi compatibility", and now it seems to be worse than ever before. Regards, Graeme -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority)
On 03.05.2017 21:47, Juha Manninen via Lazarus wrote: > Why Delphi adds the BOM? Why can't it just read the file and > understand it is UTF-8? Probably for the same reason as FPC: the default code page if no BOM is available and no command line option is set and no $codepage directive is found is ISO-8859-1. A BOM does the same as the command line option -FcUTF8 or the directive {$codepage utf8}, namely switching the source codepage to UTF-8. Only then string constants that contain UTF-8 characters are converted to UnicodeString constants. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority)
On 03.05.2017 21:47, Juha Manninen via Lazarus wrote: How many people are editing their sources in both Delphi and Lazarus? Me, but I keep the files ASCII-only because I need to target all Delphi versions down to D5 :/ My customers really demand it, unfortunately. I'd like to kill these dinosaurs, believe me - not the customers but the thousand different Delphi versions from ancient eras, during the best period even 2 of them in a year :) I still feel that code should be in English, including comments - and I am a patriot, even if it is not popular nowadays :). The utf-8 bom seems to be a stupid issue, though. Ondrej -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority)
Am 03.05.2017 14:37 schrieb "Tony Whyman via Lazarus" < lazarus@lists.lazarus-ide.org>: > On the other hand, AnsiString and UnicodeString are still separate types. Why? Why should there not be a single unified string type with (e.g.) ASCII, UTF8 and UTF-16 (or MS Unicode) being just another code page? Because indexed access to the string data would slow down quite a bit as the RTL would need to determine whether the string is a 1-Byte, 2-Byte, 4-Byte or multi Byte String. Yes the compiler could do optimizations for this inside loops, but it would definitely slow down -O- code. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority)
Am 03.05.2017 11:34 schrieb "Graeme Geldenhuys via Lazarus" < lazarus@lists.lazarus-ide.org>: > For example, take a look at ConEmu for Windows. > * Tab support built-in > * Resizeable console windows While not point and click you can resize console windows (and the window buffer) without problems. And it's even remembered *per shortcut*! > * User defined encoding per console window While not selectable upon start (I think) it can easily be changed with a command. > * Font choice Supported since at least XP > * better mouse & clipboard support If you use the PowerShell window that experience is already vastly improved. Could be that this is the case for the default console window in Windows 10 as well. > * User defined "console engine" per window or tab. > eg: I can have Bash run in one tab and the standard > windows console in another. No one stops you from running a different shell in a command window (e.g. I often switch to cmd inside PowerShell when some program give me trouble with the latter). > * color customisation Already supported since at least Windows 7 (can't currently check older versions). > I don't know why anybody would still want to run the standard Windows > console - it is 20 years behind everybody else. Because it does its job and its part of the OS without the need to install some 3rd party application. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority)
Am 03.05.2017 um 11:03 schrieb Juha Manninen via Lazarus: > How could this thing be communicated so that people understand? It would probably help if there weren't three different pages about "Unicode Support" on the wiki, all saying slightly different and conflicting things (because they talk about different things, but that's really not obvious unless you already know) and decidedly *not* saying what a user might want to know... Maybe split the technical internals from a "simpler" user's guide? Martok -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority)
On Wed, 3 May 2017 13:37:24 +0100 Tony Whyman via Lazaruswrote: >[...] > On the other hand, AnsiString and UnicodeString are still separate > types. Why? Why should there not be a single unified string type with > (e.g.) ASCII, UTF8 and UTF-16 (or MS Unicode) being just another code page? Many 8bit string functions work for any 8bit encoding, and so do many 16bit string functions for any 16bit encoding. But almost no string function works for both. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority)
On 03/05/17 09:52, Graeme Geldenhuys via Lazarus wrote: [rant] ps: Both FPC and Delphi is in such a messed up state when it comes to string and character types. It is the laughing stock of programming languages at the moment. At least EMBT is heading in the right direction with their Linux Delphi compiler - they completely removed AnsiString. FPC and Delphi can learn a huge lesson from Java and Qt in how to handle string and character types. [/rant] Regards, Graeme Is Delphi/FPC string handling that much worse than 'C'? To me, the great thing about AnsiString is that it provides unified handling of UTF8 and legacy codepages in a single managed type by including the code page id as a dynamic property of the string. On the other hand, AnsiString and UnicodeString are still separate types. Why? Why should there not be a single unified string type with (e.g.) ASCII, UTF8 and UTF-16 (or MS Unicode) being just another code page? -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority)
On Wed, May 3, 2017 at 5:59 AM, Graeme Geldenhuys via Lazaruswrote: > On 2017-05-03 01:21, Marcos Douglas B. Santos via Lazarus wrote: >> Sorry about that. I stopped using Delphi at version 7, that uses ANSI. >> I thought that Delphi nowadays was using UTF16. > > They (Delphi) loves to follow Microsoft. Files are stored in UTF-8 (this > is the norm), but they use UTF-16 internally. > > Lazarus stores files in UTF-8 and uses UTF-8 internally. > > Some background info > > UTF-16 was the first encoding implementation for Unicode - at a time > when they thought 2-bytes will be big enough for everything. They were > wrong. So then they invented UTF-8 to solve the problem. But by that > time Microsoft already standardised on UTF-16, so Delphi followed suite. > Linux, FreeBSD etc saw the light and used UTF-8 instead. Ok, thank you for these informations. best regards, Marcos Douglas -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority)
On Wed, 3 May 2017 12:03:41 +0300 Juha Manninen via Lazaruswrote: >[...] > Please also look at program LazUnicodeTest in components/lazutils/test/. > It does advanced Unicode stuff and works in both Delphi and Lazarus. I tried it: First it did not compile in Delphi, because of an unsupported inline. I fix that with an IFDEF FPC. Then it runs. The output is somewhat hard to interpret as the Windows console shows many chars as '?' and the writelns do not explain what it is supposed to show. The good news is that it works. The bad news is, that it only works because Delphi silently altered the source file and added the BOM. Back in Lazarus compiling such a file gives the error: LazUnicodeTest.lpr(28,10) Error: UTF-8 code greater than 65535 found > It means any code dealing with Unicode can do it. > > How could this thing be communicated so that people understand? > Why other Lazarus developers don't want to mention it? > I am puzzled. :( You are right, that using Unicode with Lazarus only needs a couple of rules to follow. Sharing code with Delphi adds a few more rules. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority)
Am 2017-05-03 um 11:34 schrieb Graeme Geldenhuys via Lazarus: > I don't know why anybody would still want to run the standard Windows > console - it is 20 years behind everybody else. The reason: It is available on every Windows machine. The alternatives need to be installed first so scripts designed for them don't work out of the box. -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority)
On Wed, May 3, 2017 at 12:13 PM, Ondrej Pokorny via Lazaruswrote: > Not if you need pre-unicode Delphi support :) Ok, true. IMO such old Delphi versions should not be used any more for new code. Maintenance tasks only I think. Fortunately there is again a free Delphi Starter edition. It means anybody can use the latest version. Things are surely getting better! Juha -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority)
On 03.05.2017 11:21, Juha Manninen via Lazarus wrote: Windows already supports Unicode in everything ... except for console output! Why is that? You can start the console with UTF-8 codepage: http://stackoverflow.com/questions/14109024/how-to-make-unicode-charset-in-cmd-exe-by-default Then you have full unicode (utf-8) support. Ondrej -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority)
On 2017-05-03 10:25, Ondrej Pokorny via Lazarus wrote: > You can start the console with UTF-8 codepage: > http://stackoverflow.com/questions/14109024/how-to-make-unicode-charset-in-cmd-exe-by-default > > Then you have full unicode (utf-8) support. Or use the much better console alternatives. The Windows platform is finally catching on to what was been available in X11 environments for years - multiple choice on consoles. For example, take a look at ConEmu for Windows. * Tab support built-in * Resizeable console windows * User defined encoding per console window * Font choice * better mouse & clipboard support * User defined "console engine" per window or tab. eg: I can have Bash run in one tab and the standard windows console in another. * color customisation * transparency support https://sourceforge.net/projects/conemu/ I don't know why anybody would still want to run the standard Windows console - it is 20 years behind everybody else. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority)
On Wed, May 3, 2017 at 11:52 AM, Graeme Geldenhuys via Lazaruswrote: > At least EMBT is heading in the right direction with their > Linux Delphi compiler - they completely removed AnsiString. I must agree with you. I hope it will be removed in (far) future when nobody uses the old Windows system codepages any more. Windows already supports Unicode in everything ... except for console output! Why is that? Anyway, please let's leave out encoding supremacy issues now. My point has been that our Unicode solution makes the encoding issues irrelevent. It is almost compatible at source level despite the different encodings. Think how improbable that is, yet it works. See also the encoding agnostic support provided by LazUnicode. Encoding does not matter any more, as long as it is Unicode. Juha -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority)
On 03.05.2017 11:03, Juha Manninen via Lazarus wrote: I am puzzled why there were so many misleading and confusing replies, also from knowledgeable Lazarus developers. Remember, the question was about making sources compatible with Delphi. The person (Marcos Douglas) did not know details of how strings work in Delphi and Lazarus. Now we finally have a system that allows (more or less) compatible code when using Unicode. Why was it not even mentioned by you guys? For example: Ondrej Pokorny wrote: Speaking from my experience, the only approach (not only the best one but the only one) is not to use characters above #255. Nonsense. Full Unicode is supported. Not if you need pre-unicode Delphi support :) (Well, Marcos didn't specify what Delphi version he wants to target but he stated "If Delphi sources don't use UTF8 [...]", which applies to pre-unicode Delphi versions.) Ondrej -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority)
Marcos Douglas B. Santos wrote: > I am develop on Windows. What problems do you mean? Unicode is recommended also on Windows. No worries. You don't need to use the old system codepages. People who need them must convert them explicitly because the Unicode system of Lazarus does not support them directly. > Sorry about that. I stopped using Delphi at version 7, that uses ANSI. > I thought that Delphi nowadays was using UTF16. > I will install Delphi Tokyo Starter and discover these things. You confuse separate things now. The encoding of their "String" is now UTF-16. Source files are saved as UTF-8. > But if I put theses constants as resourcestrings, it's Ok as Mattias > told me, right? I don't think it makes any difference. You can use the full Unicode in both cases. --- I am puzzled why there were so many misleading and confusing replies, also from knowledgeable Lazarus developers. Remember, the question was about making sources compatible with Delphi. The person (Marcos Douglas) did not know details of how strings work in Delphi and Lazarus. Now we finally have a system that allows (more or less) compatible code when using Unicode. Why was it not even mentioned by you guys? For example: Ondrej Pokorny wrote: > Speaking from my experience, the only approach (not only the best one but > the only one) is not to use characters above #255. Nonsense. Full Unicode is supported. Mattias Gaertner wrote: > Option a) You can use English in sources and load all non ASCII > constants via resourcestrings or similar. Then the codepage is > irrelevant. > Option b) You can store all files as UTF-8 with BOM. Then FPC will > store all non ASCII string constants as unicodestrings. Be careful when > using PChar with them. This adds implicit conversions, so it might be > slower. That must be very confusing. Why didn't you just tell him to use the default Unicode support in Lazarus which allows to write Delphi compatible code, just by remembering couple of rules. Also Tony's advice to use AnsiString explicitly is quite irresponsible for a person who looks for Delphi compatibility. AnsiString is not Delphi compatible any more in our system and it brings you back to stone-age in Delphi, to the horrors of system codepages. Is it possible that people still don't know how Delphi compatible the Lazarus Unicode system is (unless you need the old system codepages obviously)? For example Lazarus developer Werner (wp) didn't know the Ansi...() string functions, like AnsiCompareStr(), are compatible with Delphi. http://forum.lazarus.freepascal.org/index.php/topic,36664.msg244619.html#msg244619 Yes they are! Please also look at program LazUnicodeTest in components/lazutils/test/. It does advanced Unicode stuff and works in both Delphi and Lazarus. It means any code dealing with Unicode can do it. How could this thing be communicated so that people understand? Why other Lazarus developers don't want to mention it? I am puzzled. :( Juha -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority)
On 2017-05-02 09:30, Juha Manninen via Lazarus wrote: > From FPC's point of view our UTF-8 solution is a hack. FPC's point of view or Marco's point of view? Just curious - so what is FPC’s “correct” solution then for using UTF-8 and the preferred encoding? What's the alternative they offer? [rant] ps: Both FPC and Delphi is in such a messed up state when it comes to string and character types. It is the laughing stock of programming languages at the moment. At least EMBT is heading in the right direction with their Linux Delphi compiler - they completely removed AnsiString. FPC and Delphi can learn a huge lesson from Java and Qt in how to handle string and character types. [/rant] Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus