[fpc-pascal] {$H+} meaning with compiler {$mode DELPHIUNICODE}

[Jonas Maebe]

Graeme Geldenhuys wrote on Mon, 09 May 2016:

> The other problem being? How can we contribute to bringing the Unicode
> Enabled RTL up to par with Delphi, when the FPC team can't decide on
> what the RTL must be or look like?

See Tomas' mail for a start.

> When can we expect a decision from the dev team?

You've been using using FPC for long enough that you should know this  
can only be interpreted as a rhetorical question.

> I'm sure Michael will not be happy about having to dig through the wiki
> for potential documentation updates.

Before every new release, Michael asks on the core list for a list of  
new features that should be documented. I assume that having a  
complete wiki page documenting every detail is much easier than an ad  
hoc description written at that point based on the recollections of  
the person who did the work 6 months earlier.

> Plus the fact that, how much can
> you trust the wiki information, because anybody of any skill level can
> edit it.

Plus the fact that if a developer points Michael to a wiki page they  
wrote themselves, Michael can assume that person has checked it first  
for its veracity. Or, in the worst case, Michael can be pointed to a  
particular revision of that page.

>> Additionally, the wiki pages can be easily updated in real time after a
>> release when errors/omissions are seen
>
> Don't you have commit access to fpc_docs? ;-)

It is much easer to write a comprehensive document on a particular  
feature than to hunt down every corner and topic in the documentation  
that may have to be modified. Case in point: even Michael, who knows  
the documentation much better than anyone else, misses things when  
integrating such information in the documentation.

Conversely, it is presumably also much easier for someone who is  
already familiar with the language to have a single wiki page  
summarising all changes related to a particular feature, as opposed to  
having to reread the documentation from start to finish to find the  
differences.

> , while the official documentation
>> will only be regenerated when the next release is made.
>
> True, but this could easily be automated to generate interim PDF's once
> a week or once a month. Cron job -> svn up -> make -> rsync with webserver.

That would only work if only fixes would be performed to the  
documentation between two releases, while all new features would only  
be added the day before the new release. Or if you would start  
branching the documentation. Those are not things we want to do.


Jonas