Re: [fpc-devel] Where are parser sources?

2013/1/4 Michael Van Canneyt > It's probably easier to restore the grammar from pparser than from the > compiler sources. > > Michael. > Now I look "Free Pascal :Reference guide." - ref.pdf and there is grammar Andrzej Borucki ___ fpc-devel maillist

Re: [fpc-devel] String handling in trunk (was utf8 in 2.6.0)

On Sat, 5 Jan 2013, Paul Ishenin wrote: 05.01.13, 23:54, Michael Van Canneyt пишет: You are very much wrong. To start with, resource strings are not stored as Win32 resources. I personally think that resources should be stored in their native formats where is possible. This will allow to

Re: [fpc-devel] String handling in trunk (was utf8 in 2.6.0)

05.01.13, 23:54, Michael Van Canneyt пишет: You are very much wrong. To start with, resource strings are not stored as Win32 resources. I personally think that resources should be stored in their native formats where is possible. This will allow to change them using software designed for th

Re: [fpc-devel] String handling in trunk (was utf8 in 2.6.0)

On Sat, 5 Jan 2013, Hans-Peter Diettrich wrote: Michael Van Canneyt schrieb: On Sat, 5 Jan 2013, Jonas Maebe wrote: On 05 Jan 2013, at 12:53, Paul Ishenin wrote: ResourceStrings are stored as AnsiString type with 0 codepage (as I remember). Delphi now stores ResourceStrings as UnicodeS

Re: [fpc-devel] String handling in trunk (was utf8 in 2.6.0)

Michael Van Canneyt schrieb: On Sat, 5 Jan 2013, Jonas Maebe wrote: On 05 Jan 2013, at 12:53, Paul Ishenin wrote: ResourceStrings are stored as AnsiString type with 0 codepage (as I remember). Delphi now stores ResourceStrings as UnicodeString type. I think FPC will follow this in m_defau

Re: [fpc-devel] String handling in trunk (was utf8 in 2.6.0)

On Sat, 5 Jan 2013, Sven Barth wrote: On 05.01.2013 14:16, Michael Van Canneyt wrote: On Sat, 5 Jan 2013, Jonas Maebe wrote: On 05 Jan 2013, at 13:10, Michael Van Canneyt wrote: On Sat, 5 Jan 2013, Jonas Maebe wrote: On 05 Jan 2013, at 12:53, Paul Ishenin wrote: ResourceStrings ar

Re: [fpc-devel] String handling in trunk (was utf8 in 2.6.0)

On 05.01.2013 14:16, Michael Van Canneyt wrote: On Sat, 5 Jan 2013, Jonas Maebe wrote: On 05 Jan 2013, at 13:10, Michael Van Canneyt wrote: On Sat, 5 Jan 2013, Jonas Maebe wrote: On 05 Jan 2013, at 12:53, Paul Ishenin wrote: ResourceStrings are stored as AnsiString type with 0 codepag

Re: [fpc-devel] utf8 in 2.6.0

> For Lazarus: > - works with fpc 2.6.x and 2.7.1 > - LCL and most code expect ansistrings to hold UTF-8. > - pascal sources, lfm, po files are stored in UTF-8 without BOM. > Special care has to be taken, when using widestrings/unicodestring. > - there are UTF-8 functions and classes (most in pac

Re: [fpc-devel] utf8 in 2.6.0

On Sat, 5 Jan 2013 13:06:42 + Frank Church wrote: >[...] > It is obvious that Unicode is not a simple topic and among FPC/Lazarus > developers/contributors,I suspect that few if any at all, have a detailed > grasp of how it all hangs together in the current state of implementation. > It bring

Re: [fpc-devel] utf8 in 2.6.0

Martin Schreiber schrieb: but I fear we can not use that information for development with Free Pascal because: " The string is represented internally as a Unicode string encoded as UTF-16. Characters in the Basic Multilingual Plane (BMP) take 2 bytes, and characters not in the BMP require 4 b

Re: [fpc-devel] String handling in trunk (was utf8 in 2.6.0)

On Sat, 5 Jan 2013, Jonas Maebe wrote: On 05 Jan 2013, at 13:10, Michael Van Canneyt wrote: On Sat, 5 Jan 2013, Jonas Maebe wrote: On 05 Jan 2013, at 12:53, Paul Ishenin wrote: ResourceStrings are stored as AnsiString type with 0 codepage (as I remember). Delphi now stores ResourceStr

Re: [fpc-devel] utf8 in 2.6.0

On 15 December 2012 18:35, Martin wrote: > I am trying to figure out how to do that, or what I do wrong. I found a > page about $codepage, but it did not help http://wiki.freepascal.org/** > LCL_Unicode_Support > I didnt find the fpc specific page,

Re: [fpc-devel] String handling in trunk (was utf8 in 2.6.0)

> Yes, the exception is probably UTF-8 on Unix systems, but is that really > worth it to complicate the compiler and RTL? Resourcestings are generally > not used in performance-critical code, I'd assume. Always using UTF-8 is > however also fine for me, I do vote for UTF-8 > btw. I just don't b

Re: [fpc-devel] String handling in trunk (was utf8 in 2.6.0)

On 05 Jan 2013, at 13:33, Martin Schreiber wrote: > On Saturday 05 January 2013 12:57:44 Jonas Maebe wrote: >> On 05 Jan 2013, at 12:53, Martin Schreiber wrote: >>> So compiled with -Fcutf8 >>> " >>> unicodestringvar:= 'Best'#228'tigung'; >>> " >>> produces a different result on fixes_2_6 and tru

Re: [fpc-devel] String handling in trunk (was utf8 in 2.6.0)

On Saturday 05 January 2013 12:57:44 Jonas Maebe wrote: > On 05 Jan 2013, at 12:53, Martin Schreiber wrote: > > So compiled with -Fcutf8 > > " > > unicodestringvar:= 'Best'#228'tigung'; > > " > > produces a different result on fixes_2_6 and trunk? I assume in trunk > > there will be a compile error

Re: [fpc-devel] String handling in trunk (was utf8 in 2.6.0)

On 05 Jan 2013, at 13:10, Michael Van Canneyt wrote: > On Sat, 5 Jan 2013, Jonas Maebe wrote: > >> >> On 05 Jan 2013, at 12:53, Paul Ishenin wrote: >> >>> ResourceStrings are stored as AnsiString type with 0 codepage (as I >>> remember). Delphi now stores ResourceStrings as UnicodeString type

Re: [fpc-devel] utf8 in 2.6.0

On Saturday 05 January 2013 13:01:44 Michael Van Canneyt wrote: > > Seeing that you have already invested lots of time in FPC, you could also > ask yourself > > 'How can I help improve fpc so it remains the right tool for my purposes' ? > > Or have you decided that cooperation with the FPC team is

Re: [fpc-devel] String handling in trunk (was utf8 in 2.6.0)

On Sat, 5 Jan 2013, Jonas Maebe wrote: On 05 Jan 2013, at 12:53, Paul Ishenin wrote: ResourceStrings are stored as AnsiString type with 0 codepage (as I remember). Delphi now stores ResourceStrings as UnicodeString type. I think FPC will follow this in m_default_unicodestring modeswitch.

Re: [fpc-devel] String handling in trunk (was utf8 in 2.6.0)

On 05 Jan 2013, at 12:53, Paul Ishenin wrote: > ResourceStrings are stored as AnsiString type with 0 codepage (as I > remember). Delphi now stores ResourceStrings as UnicodeString type. I think > FPC will follow this in m_default_unicodestring modeswitch. It would probably even be better to al

Re: [fpc-devel] utf8 in 2.6.0

On Sat, 5 Jan 2013, Martin Schreiber wrote: On Saturday 05 January 2013 12:39:21 Jonas Maebe wrote: Then maybe I should just stop completely answering any questions about this, because apparently not answering completely enough to your liking gets interpreted as telling you to shut up or get

Re: [fpc-devel] utf8 in 2.6.0

On Saturday 05 January 2013 12:39:21 Jonas Maebe wrote: > > Then maybe I should just stop completely answering any questions about > this, because apparently not answering completely enough to your liking > gets interpreted as telling you to shut up or getting moderated. Just like > Sven I don't un

Re: [fpc-devel] String handling in trunk (was utf8 in 2.6.0)

On 05 Jan 2013, at 12:53, Martin Schreiber wrote: > So compiled with -Fcutf8 > " > unicodestringvar:= 'Best'#228'tigung'; > " > produces a different result on fixes_2_6 and trunk? I assume in trunk there > will be a compile error? No. In both cases it results in a widestring with this content:

Re: [fpc-devel] String handling in trunk (was utf8 in 2.6.0)

05.01.13, 19:40, Jonas Maebe пишет: You can put anything in it and it may or may not work depending on the current system code page, but afaik the only thing that is guaranteed to work at this time is plain ASCII. ResourceStrings are stored as AnsiString type with 0 codepage (as I remember)

Re: [fpc-devel] String handling in trunk (was utf8 in 2.6.0)

On Saturday 05 January 2013 12:28:03 Jonas Maebe wrote: > Alternatively, in both cases you can instead define a > unicodestring/widestring constant instead of an ansistring/shortstring > constant by embedding widechar constants in the character sequence. Such > widechar constants are of the form #

Re: [fpc-devel] String handling in trunk (was utf8 in 2.6.0)

On 05 Jan 2013, at 12:36, Sven Barth wrote: > On 05.01.2013 12:28, Jonas Maebe wrote: >>> And again, sorry for the impertinence, how do resource strings fit in the >>> string handling scenario of Free Pascal trunk? >> >> Unicode support for resourcestrings is still not available in FPC trunk. >

Re: [fpc-devel] utf8 in 2.6.0

On 05 Jan 2013, at 12:16, Martin Schreiber wrote: > On Saturday 05 January 2013 11:42:29 Sven Barth wrote: >> I think it was more meant in the context of the mailing list instead of >> a technical context. Like in "we had this topic a thousand times and >> maybe it's better we shut up about it no

Re: [fpc-devel] String handling in trunk (was utf8 in 2.6.0)

On 05.01.2013 12:28, Jonas Maebe wrote: And again, sorry for the impertinence, how do resource strings fit in the string handling scenario of Free Pascal trunk? Unicode support for resourcestrings is still not available in FPC trunk. They can currently still only be used safely for ASCII conte

Re: [fpc-devel] String handling in trunk (was utf8 in 2.6.0)

On 05 Jan 2013, at 12:12, Martin Schreiber wrote: > Thank you very much for the detailed explanation. What I could not found in > all the answers (probably it is my ignorance of the English language), is, > does #n mean a utf16 code unit as in Delphi XE3 or does it denote something > other? I

Re: [fpc-devel] utf8 in 2.6.0

On Saturday 05 January 2013 11:42:29 Sven Barth wrote: > On 05.01.2013 11:30, Jonas Maebe wrote: > > For example, I said that basically nothing changed in 2.7.x compared to > > 2.6.x, except that certain string constants are no longer automatically > > converted to utf-16 at compile time, and then

Re: [fpc-devel] String handling in trunk (was utf8 in 2.6.0)

On Saturday 05 January 2013 11:30:42 Jonas Maebe wrote: [...] > > For example, I said that basically nothing changed in 2.7.x compared to > 2.6.x, except that certain string constants are no longer automatically > converted to utf-16 at compile time, and then you ask "Or should we not > touch the t

Re: [fpc-devel] utf8 in 2.6.0

On 05.01.2013 11:30, Jonas Maebe wrote: For example, I said that basically nothing changed in 2.7.x compared to 2.6.x, except that certain string constants are no longer automatically converted to utf-16 at compile time, and then you ask "Or should we not touch the theme strings and FPC anymor

Re: [fpc-devel] utf8 in 2.6.0

On 05 Jan 2013, at 10:29, Martin Schreiber wrote: > Are these stupid questions? No, but I seem to be unable to explain how it works since you keep asking about things I already tried to explain before, but I clearly failed to do properly. I can keep repeating myself, but I'm not sure whether t

Re: [fpc-devel] utf8 in 2.6.0

On Tuesday 01 January 2013 18:36:01 Martin Schreiber wrote: > > So #n or #nn or #nnn or # or #n always means Unicode codepoint and > will be at compiletime converted to an 8bit character sequence depending on > {$codepage} and stored in a cpstrnew with the codepage of {$codepage} if > assig