First, thanks to all involved in documenting the existing FPC trunk Unicode situation on the wiki. Exactly the kind of docs I was looking for!

I'm trying to avoid ambiguity for an UTF8 (without BOM) encoded file and
tried this:
{$ifdef fpc}
  //Explicitly specify this is an UTF8 encoded file.
  //Alternative would be UTF8 with BOM but writing UTF8 BOM is bad practice.
  //See
http://wiki.lazarus.freepascal.org/FPC_Unicode_support#String_constants
  {$codepage 65001} //utf8
{$endif fpc}
However, I get
stringtests.pas(5,4) Error: Unknown codepage "65001"

Replacing the {$codepage 65001} with
{$codepage UTF8}
does seem to work.

http://wiki.lazarus.freepascal.org/FPC_Unicode_support#Code_page_identifiers mentions identifiers follow the Windows numbers but obviously you have to spell out UTF8 at least rather than specifying the number. Is there a list of these constants somewhere?

Thanks,
Reinier

The codepage names used by the codepage directive are (unfortunately, I guess) unrelated to the code page numbers: http://www.freepascal.org/docs-html/prog/progsu88.html

They are the names of individual codepage units exposed by the charset unit, which have names such as cp866 and cp1251. In fact, in general I think you can just prefix the code page number with "cp" (other than for utf8, which is built into the compiler and can be accessed via utf8 or utf-8).

Note that this codepage functionality has been in FPC since 2.4.x already (or maybe 2.6.0). It's not new in any way.

Jonas

Thanks a lot, Jonas.

I think that adding links to the manual pages on the wiki is generally not a good idea, because the names of those pages change with every FPC release. The exception are pages for units documentation, as those have fixed names.

The way I find such pages is via google, so maybe a link to https://www.google.be/search?q=site:www.freepascal.org+codepage is better. At least it will always be up-to-date.

Jonas

I see your point, but I think that people should just regularly update the wiki as information gets outdated etc.
If people cannot go from a broken link to typing in the keyword it points to in a search engine, well....

That is a dangerous path you step onto.
There are so many things I think are so incredibly obvious ;-)

Michael.

You did not notice I have walked that path for a while now?

There are so many things I think are so incredibly obvious ;-)

You know, the wiki is free to edit: go ahead.
I don't mind if somebody else thinks this is so important that he wants to take the time to remove info; a corrolary IMO is that people who take the trouble to add info, update the wiki etc should do as they see fit. (IOW: I'm not looking for edit wars and respect contributions/opinions from people like Jonas and DoDi who put effort into updating the wiki)

A counter example: after trying to get practical examples, concrete documentation - e.g. the actual names for ($codepage xxx} into fpcdocs (see bug report I raised about console mode applications that worked in 2.6 and stopped working in trunk) I was told that isn't the way things are done.
Now I'm not pushing any more and just put useful information on the wiki.

?

I was not referring to the wiki, but to the implicit assumption that people will go to the trouble of using a search engine upon receiving a broken link (as you seem to expect).

Concerning the rest of your answer: I really have no idea what you are talking about.

My apologies if I upset you in any way.

Michael.

Well it depends. To what lengths is one willing to go to make things idiot-proof... and where do the disadvantages outweigh the disadvantages. Obviously a tradeoff that differs per individual/doc writer.

Concerning the rest of your answer: I really have no idea what you are talking about. My apologies if I upset you in any way.

Well, consider me un-upset ;) - I obviously completely misunderstood you ;)

@Michael: Do you think it would be somehow possible to generate persistent links for the language reference, etc. , maybe based on the topic names?

Regards,
Sven