pasdoc-main

[Pasdoc-main] Escape character in @latex, @html

[Daniel A. <Dan...@lo...>]

Hi all,

the parameter of @latex and @html is just passed through and not 
interpreted. This causes problems, if you use some pasdoc escape 
character inside the parameter text, specially the brackets, as they are 
interpreted as a parameter delimiter.
To solve this it's possible to mark the inside brackets with the @-tag, 
i.e. @( @) and pasdoc recognizes the parameter correctly. But as pasdoc 
is not interpreting the parameter at all, the @) and @( goes unconverted 
to the output text.

In my opinion pasdoc should always parse for @), @( and @@ and remove 
the prevailing @ character. Do you agree with it?

I tried to fix this problem but was not yet able to find the correct 
place in the code. I guess somewhere in TTagManager.CoreExecute... Does 
anyone has a tip where to look?

Can this change be applied for all tags or should I restrict it to 
@latex and @html?

Daniel

[Pasdoc-main] [ pasdoc-Feature Requests-3485296 ] attributes support

[SourceForge.net <no...@so...>]

Feature Requests item #3485296, was opened at 2012-02-07 03:44
Message generated for change (Comment added) made by kambi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=354213&aid=3485296&group_id=4213

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Closed
Priority: 5
Private: No
Submitted By: Vasek Cejka (vcejka)
Assigned to: Nobody/Anonymous (nobody)
Summary: attributes support

Initial Comment:
I'm working on support for attributes added to Delphi at version 2010. I need it, because parser fails when some attribute is found. It is not finished yet, but I have no experience with FPC. If someone has some idea or demand, please post it.

Here are my current notes on implementation:
Changes to PasDoc:

Tokenizer:
-	added token Attribute + token string
-	defined constant AttributeStart + AttributeEnd ([])

Items:
-	To TPasItem added property Attributes as TstringVector containing list of attributes defined for this item. It is created in constructor and destroyed in destructor

Parser:
-	added private boolean field AttributeIsPossible to Tparser
-	added private field CurrentAttributes (TstringVector) to Tparser, created in constructor and destroyed in destructor
-	Attributes are found in square brackets before item. If parser finds them, stores them to CurrentAttributes field.
-	Once some attributes is defined when CDFP is analyzed, it is moved from CurrentAtributes to Attributes field of TPasMethod in TParser.ParseCDFP
-	Once some attributes is defined when Constant is analyzed, it is moved from CurrentAtributes to Attributes field of TPasConstant in TParser.ParseConstant
-	Once some attributes is defined when Enum is analyzed, it is moved from CurrentAtributes to Attributes field of TPasEnum in TParser.ParseEnum
-	Once some attributes is defined when Property is analyzed, it is moved from CurrentAtributes to Attributes field of TPasProperty in TParser.ParseProperty
-	Once some attributes is defined when some field of some record is analyzed, it is moved from CurrentAtributes to Attributes field of TPasFieldVariable in TParser.ParseRecordCase, but it is not possible to apply attributes to cases of record fields.
-	Once some attributes is defined when type is analyzed, it is moved from CurrentAtributes to Attributes field of TPasType in TParser.ParseType
-	Once some attributes is defined when field of class or record is analyzed, it is moved from CurrentAtributes to Attributes field of TPasFieldVariable in TParser. ParseFieldsVariables
-	Parsing of attributes is disabled when interface section of some unit is entered and enabled when some type starts to be parsed (TParser.ParseInterfaceSection)
-	Parsing of attributes is disabled when new type identifier is found and type definition is expected (TParser.ParseType)
-	When attribute is possible, it is extracted by TParser.PeekNextToken. When identifier is found, there can be no attribute, so checking is disabled until next semicolon. When attribute is possible, left square bracket is checked. If found, tokens until next right squate bracket are taken as attribute.
-	When members of class, interface or object are analysed, it is supposed that attribute can be just in front of keyword or identifier, so checking is enabled at the beginning, token is taken and attributes checking is disabled again (TParser.ParseCioMembers). When end directive occurs (end of CIO), attributes, even if found and not used, are cleared.
-	Also when CIO type declaration is parsed, parsing of attributes is enabled at the beginning, token is taken and parsing of attributes is disabled. When CIO is found, founf attributes are moved to Attributes field of TPasCio. (TParser.ParseCioTypeDecl)
-	Internal types of CIO are not parsed for attributes at this moment!!!  Should it be added?


----------------------------------------------------------------------

>Comment By: Michalis Kamburelis (kambi)
Date: 2012-03-05 09:26

Message:
The last comment from anonymous (2012-03-05 07:00) on this issue was
obviously by a spammer. I removed the ability for anonymous to post
comments in "Patches" and "Feature Requests" trackers (for "Bugs" tracker,
it was already disabled since some time), and I removed the spammer
comment.

----------------------------------------------------------------------

Comment By: Michalis Kamburelis (kambi)
Date: 2012-02-15 14:41

Message:
Closed (implemented) by VCejka patch in "[ pasdoc-Patches-3487782 ] Support
for attributes".

----------------------------------------------------------------------

Comment By: Michalis Kamburelis (kambi)
Date: 2012-02-07 04:13

Message:
On the other hand, it's a feature request, so it's probably better to leave
it open :) In any case, I understand that you're volunteering to send a
patch for this some day soon :)

Oh, and as for FPC: I don't think FPC can parse Delphi 2010 attributes now.
PasDoc source code of course must be compileable by FPC (as well as
Delphi), but don't worry about it if you don't want to. I use FPC and will
fix eventual incompatibilities.

----------------------------------------------------------------------

Comment By: Michalis Kamburelis (kambi)
Date: 2012-02-07 04:07

Message:
From a quick reading, everything seems sensible, you're most welcome to
work on it and I'll apply :) Note that it's better to discuss stuff on a
maling list (https://lists.sourceforge.net/lists/listinfo/pasdoc-main ),
tracker should be used for things that can eventually be closed as "done".
I currently close this issue (although you can still post comments and
reopen it), as there's nothing for me to do here :)

As for:
> Internal types of CIO are not parsed for attributes at this moment!!!
Should it be added?

Internal types are parsed and handled in SVN version of PasDoc, thanks to
Arno Garrels. For example, this works:
https://pasdoc.svn.sourceforge.net/svnroot/pasdoc/trunk/tests/ok_nested_types.pas
. You should definitely prepare your patches against SVN version of the
pasdoc source code. Instructions for SVN on main www page,
http://pasdoc.sipsolutions.net/ , basically just "svn co
https://pasdoc.svn.sourceforge.net/svnroot/pasdoc/trunk".

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=354213&aid=3485296&group_id=4213

[Pasdoc-main] [ pasdoc-Feature Requests-3485296 ] attributes support

[SourceForge.net <no...@so...>]

Feature Requests item #3485296, was opened at 2012-02-07 03:44
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=354213&aid=3485296&group_id=4213

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Closed
Priority: 5
Private: No
Submitted By: Vasek Cejka (vcejka)
Assigned to: Nobody/Anonymous (nobody)
Summary: attributes support

Initial Comment:
I'm working on support for attributes added to Delphi at version 2010. I need it, because parser fails when some attribute is found. It is not finished yet, but I have no experience with FPC. If someone has some idea or demand, please post it.

Here are my current notes on implementation:
Changes to PasDoc:

Tokenizer:
-	added token Attribute + token string
-	defined constant AttributeStart + AttributeEnd ([])

Items:
-	To TPasItem added property Attributes as TstringVector containing list of attributes defined for this item. It is created in constructor and destroyed in destructor

Parser:
-	added private boolean field AttributeIsPossible to Tparser
-	added private field CurrentAttributes (TstringVector) to Tparser, created in constructor and destroyed in destructor
-	Attributes are found in square brackets before item. If parser finds them, stores them to CurrentAttributes field.
-	Once some attributes is defined when CDFP is analyzed, it is moved from CurrentAtributes to Attributes field of TPasMethod in TParser.ParseCDFP
-	Once some attributes is defined when Constant is analyzed, it is moved from CurrentAtributes to Attributes field of TPasConstant in TParser.ParseConstant
-	Once some attributes is defined when Enum is analyzed, it is moved from CurrentAtributes to Attributes field of TPasEnum in TParser.ParseEnum
-	Once some attributes is defined when Property is analyzed, it is moved from CurrentAtributes to Attributes field of TPasProperty in TParser.ParseProperty
-	Once some attributes is defined when some field of some record is analyzed, it is moved from CurrentAtributes to Attributes field of TPasFieldVariable in TParser.ParseRecordCase, but it is not possible to apply attributes to cases of record fields.
-	Once some attributes is defined when type is analyzed, it is moved from CurrentAtributes to Attributes field of TPasType in TParser.ParseType
-	Once some attributes is defined when field of class or record is analyzed, it is moved from CurrentAtributes to Attributes field of TPasFieldVariable in TParser. ParseFieldsVariables
-	Parsing of attributes is disabled when interface section of some unit is entered and enabled when some type starts to be parsed (TParser.ParseInterfaceSection)
-	Parsing of attributes is disabled when new type identifier is found and type definition is expected (TParser.ParseType)
-	When attribute is possible, it is extracted by TParser.PeekNextToken. When identifier is found, there can be no attribute, so checking is disabled until next semicolon. When attribute is possible, left square bracket is checked. If found, tokens until next right squate bracket are taken as attribute.
-	When members of class, interface or object are analysed, it is supposed that attribute can be just in front of keyword or identifier, so checking is enabled at the beginning, token is taken and attributes checking is disabled again (TParser.ParseCioMembers). When end directive occurs (end of CIO), attributes, even if found and not used, are cleared.
-	Also when CIO type declaration is parsed, parsing of attributes is enabled at the beginning, token is taken and parsing of attributes is disabled. When CIO is found, founf attributes are moved to Attributes field of TPasCio. (TParser.ParseCioTypeDecl)
-	Internal types of CIO are not parsed for attributes at this moment!!!  Should it be added?


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2012-03-05 07:00

Message:
gfHrCq  <a href="http://fwjsafmmdokl.com/">fwjsafmmdokl</a>,
[url=http://cmzfbjxjzmvu.com/]cmzfbjxjzmvu[/url],
[link=http://dtcgkedbpiaz.com/]dtcgkedbpiaz[/link],
http://hpwvxylvvveb.com/

----------------------------------------------------------------------

Comment By: Michalis Kamburelis (kambi)
Date: 2012-02-15 14:41

Message:
Closed (implemented) by VCejka patch in "[ pasdoc-Patches-3487782 ] Support
for attributes".

----------------------------------------------------------------------

Comment By: Michalis Kamburelis (kambi)
Date: 2012-02-07 04:13

Message:
On the other hand, it's a feature request, so it's probably better to leave
it open :) In any case, I understand that you're volunteering to send a
patch for this some day soon :)

Oh, and as for FPC: I don't think FPC can parse Delphi 2010 attributes now.
PasDoc source code of course must be compileable by FPC (as well as
Delphi), but don't worry about it if you don't want to. I use FPC and will
fix eventual incompatibilities.

----------------------------------------------------------------------

Comment By: Michalis Kamburelis (kambi)
Date: 2012-02-07 04:07

Message:
From a quick reading, everything seems sensible, you're most welcome to
work on it and I'll apply :) Note that it's better to discuss stuff on a
maling list (https://lists.sourceforge.net/lists/listinfo/pasdoc-main ),
tracker should be used for things that can eventually be closed as "done".
I currently close this issue (although you can still post comments and
reopen it), as there's nothing for me to do here :)

As for:
> Internal types of CIO are not parsed for attributes at this moment!!!
Should it be added?

Internal types are parsed and handled in SVN version of PasDoc, thanks to
Arno Garrels. For example, this works:
https://pasdoc.svn.sourceforge.net/svnroot/pasdoc/trunk/tests/ok_nested_types.pas
. You should definitely prepare your patches against SVN version of the
pasdoc source code. Instructions for SVN on main www page,
http://pasdoc.sipsolutions.net/ , basically just "svn co
https://pasdoc.svn.sourceforge.net/svnroot/pasdoc/trunk".

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=354213&aid=3485296&group_id=4213

[Pasdoc-main] New PasDoc developer: VCejka

[Michalis K. <mic...@gm...>]

Hi everyone,

As you probably noticed, we recently got three patches from developer 
VCejka, to support HelpInsight comments, parse Delphi attributes and 
"final" directive. They were all of good quality, and I was able to 
apply them immediately without any hassles.

So, I just added VCejka to the developers of PasDoc on SourceForge, 
granting permission to directly commit changes to our SVN repository.

Welcome new developer! :)
Michalis

[Pasdoc-main] [ pasdoc-Patches-3488107 ] Added support for final directive

[SourceForge.net <no...@so...>]

Patches item #3488107, was opened at 2012-02-16 00:11
Message generated for change (Comment added) made by kambi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=304213&aid=3488107&group_id=4213

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: VCejka (vcejka)
>Assigned to: Michalis Kamburelis (kambi)
Summary: Added support for final directive

Initial Comment:
Thank you very much for wonderful, fast, and kind cooperation! I'm sending yet another small patch, which adds support for final directive. Until now, when parser found it, it was classified as identifier and parser then failed because of no declaration - and documentation for the whole unit was not generated.

----------------------------------------------------------------------

>Comment By: Michalis Kamburelis (kambi)
Date: 2012-02-16 09:26

Message:
Thank you for the patch, applied :)

I added testcase tests/ok_final.pas for it, the result is on
http://pasdoc.sourceforge.net/correct_tests_output/html/ok_final/ok_final.TMyObject.html
.

In unrelated news: after three good patches, I want to give you SVN commit
access :) I'll notify you in private (through SourceForge "send message"
facility, so you should get email about this), and also I'll send a message
to pasdoc-main mailing list about it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=304213&aid=3488107&group_id=4213

[Pasdoc-main] [ pasdoc-Patches-3488107 ] Added support for final directive

[SourceForge.net <no...@so...>]

Patches item #3488107, was opened at 2012-02-16 00:11
Message generated for change (Tracker Item Submitted) made by vcejka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=304213&aid=3488107&group_id=4213

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: VCejka (vcejka)
Assigned to: Nobody/Anonymous (nobody)
Summary: Added support for final directive

Initial Comment:
Thank you very much for wonderful, fast, and kind cooperation! I'm sending yet another small patch, which adds support for final directive. Until now, when parser found it, it was classified as identifier and parser then failed because of no declaration - and documentation for the whole unit was not generated.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=304213&aid=3488107&group_id=4213

[Pasdoc-main] [ pasdoc-Patches-3487782 ] Support for attributes

[SourceForge.net <no...@so...>]

Patches item #3487782, was opened at 2012-02-15 01:00
Message generated for change (Comment added) made by kambi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=304213&aid=3487782&group_id=4213

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: VCejka (vcejka)
>Assigned to: Michalis Kamburelis (kambi)
Summary: Support for attributes

Initial Comment:
Attributes were added to Delphi since v2010, but their present in the source code caused PasDoc to fail. This patch adds support for finding them and generate their documentation in HTML generator.
Attributes are quite complex and their syntax can be easily mixed with other pascal syntax elements, like enumeration. I tested them on some medium scale project (<100 units), but still I'm not sure if I chekced everything. So if you find some bug, please make a report and contact me.
Suppose this patch as a beta release. If it will be accepted, support for other generators etc. can be added.
Because of generator, there should be update of language files preformed for "Attributes" string.

There is a list of souce code modification with short explanation of implementation:

Changes to PasDoc:

Items:
-	To TPasItem added property Attributes as TStringPairVector containing list of attributes defined for this item. Name property containt attribute class name, Value property contains parameters. Method SetAttributes is added, it assigns given string pair vector to PasItem and creates new one returning it back in var param

Parser:
-	added private boolean field AttributeIsPossible to Tparser
-	added private field CurrentAttributes (TStringPairVector) to Tparser, created in constructor and destroyed in destructor
-	Attributes are found in square brackets before item. If parser finds them, stores them to CurrentAttributes field and then moves them to Attributes property of appropriate TPasItem
-	Detected attributes:
o	Of constructor, destructor, function or procedure of class or record – in ParseCDFP, set to TPasMethod
o	Of Constant – in ParseConstant, set to TPasConstant
o	Of Enum – in ParseEnum, set to TPasEnum
o	Of property of class or record – in ParseProperty, set to TPasProperty
o	Of case field of class or record – in ParseRecordCase, set to TPasFieldVariable
o	Of field of class or record – in ParseFieldsVariables, set to TpasFieldVariable
o	Of class or record declaration – in ParseCioTypeDecl, set to TPasCio
o	Of any type – in ParseType, set to TPasType
-	in current Delphi implementation Constants cannot have attributes defined, but parser handles it
-	it is not possible to apply attributes to variant cases of record fields, so parsing is temporalily disabled and then restored to original state (TParser.ParseRecordCase).
-	Parsing of attributes is disabled when interface section of some unit is entered and enabled when some type keyword occurs (TParser.ParseInterfaceSection)
-	Parsing of attributes is disabled when new type identifier is found and type definition is expected (TParser.ParseType), but it is enabled again when identifier declaration is parsed (TParser.ParseInterfaceSection)
-	Parsing of attributes is temporalily disabled when skipping declaration (TParser.SkipDeclaration)
-	When attribute is possible, it is extracted by TParser.PeekNextToken. When identifier is found, there can be no attribute, so checking is disabled until next semicolon. When attribute is possible, left square bracket is checked. If found, tokens until next right squate bracket are taken as attribute. There might be square brackets as part of attribute parameres, i.e. sets, so inner brackets are ignored. There can be more attributes defined in 1 pair of square brackets, separated by comma, but comma can also separate parameters of attribute. When comma is used inside parenthesis, it is understood as parameter separator, otherwise it is used as attribute separator.
-	When members of class, interface or object are analysed, it is supposed that attribute can be just in front of keyword or identifier, so checking is enabled at the beginning, token is taken and attributes checking is disabled again (TParser.ParseCioMembers). When end directive occurs (end of CIO), attributes, even if found and not used, are cleared.
-	Also when CIO type declaration is parsed, parsing of attributes is enabled at the beginning, token is taken and parsing of attributes is disabled.
-	Internal types of CIO are not parsed for attributes at this moment!!!  Should it be added?
-	When square bratcket is found in TParser.PeekNextToken but string follows instead of identifier, it is not supposed to be attribute, but GUID. It is also added as attribute with fake attribute class name GUID

GetHtml:
-	Added WriteAttributes procedure to TGenericHTMLDocGenerator .WriteItemLongDescription

Languages:
-	added item trAttributes to TtranslationID enumeration. Translation must be added to lang/*.inc files, added to english and czech translation files, all other set to „ToDo“ string
-	style „attributes“ can be added to *.css for HTMLDocGenerator


----------------------------------------------------------------------

>Comment By: Michalis Kamburelis (kambi)
Date: 2012-02-15 15:13

Message:
Thank you very much, your patch is applied :) I only did very minor changes
(you mistakenly moved the comment for FCachedUnitRelativeQualifiedName in
PasDoc_Items.pas, and do not add UTF8 BOM to files xxxutf8.inc). Everything
was quite perfect and straightfoward to understand, and thanks for detailed
desciption.

Oh, one problem was uncovered by testsuite: your changes make guid in
interfaces visible as an attribute. This is nice and useful, but it causes
confusing warnings displayed for each interface, like:

  Warning[1]: Could not resolve link "GUID" (from description of
"ok_dispid_method.INetFwOpenPortsDisp")

I simply fixed it by adding a check "if name = 'GUID' then" inside
WriteAttributes. The name 'GUID' is kind of special, so I guess this is
justified (but feel welcome to propose a different solution to this).

I added a testcase for this features to tests/ok_attributes.pas file. You
can see how it looks on
http://pasdoc.sourceforge.net/correct_tests_output/html/ok_attributes/ok_attributes.TPerson.html
. I just used a trivial example of attributes from
http://www.malcolmgroves.com/blog/?p=530 . Feel welcome to send patches
that extend this testcase, to cover as much as possible tricky cases.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=304213&aid=3487782&group_id=4213

[Pasdoc-main] [ pasdoc-Feature Requests-3485296 ] attributes support

[SourceForge.net <no...@so...>]

Feature Requests item #3485296, was opened at 2012-02-07 03:44
Message generated for change (Comment added) made by kambi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=354213&aid=3485296&group_id=4213

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Priority: 5
Private: No
Submitted By: VCejka (vcejka)
Assigned to: Nobody/Anonymous (nobody)
Summary: attributes support

Initial Comment:
I'm working on support for attributes added to Delphi at version 2010. I need it, because parser fails when some attribute is found. It is not finished yet, but I have no experience with FPC. If someone has some idea or demand, please post it.

Here are my current notes on implementation:
Changes to PasDoc:

Tokenizer:
-	added token Attribute + token string
-	defined constant AttributeStart + AttributeEnd ([])

Items:
-	To TPasItem added property Attributes as TstringVector containing list of attributes defined for this item. It is created in constructor and destroyed in destructor

Parser:
-	added private boolean field AttributeIsPossible to Tparser
-	added private field CurrentAttributes (TstringVector) to Tparser, created in constructor and destroyed in destructor
-	Attributes are found in square brackets before item. If parser finds them, stores them to CurrentAttributes field.
-	Once some attributes is defined when CDFP is analyzed, it is moved from CurrentAtributes to Attributes field of TPasMethod in TParser.ParseCDFP
-	Once some attributes is defined when Constant is analyzed, it is moved from CurrentAtributes to Attributes field of TPasConstant in TParser.ParseConstant
-	Once some attributes is defined when Enum is analyzed, it is moved from CurrentAtributes to Attributes field of TPasEnum in TParser.ParseEnum
-	Once some attributes is defined when Property is analyzed, it is moved from CurrentAtributes to Attributes field of TPasProperty in TParser.ParseProperty
-	Once some attributes is defined when some field of some record is analyzed, it is moved from CurrentAtributes to Attributes field of TPasFieldVariable in TParser.ParseRecordCase, but it is not possible to apply attributes to cases of record fields.
-	Once some attributes is defined when type is analyzed, it is moved from CurrentAtributes to Attributes field of TPasType in TParser.ParseType
-	Once some attributes is defined when field of class or record is analyzed, it is moved from CurrentAtributes to Attributes field of TPasFieldVariable in TParser. ParseFieldsVariables
-	Parsing of attributes is disabled when interface section of some unit is entered and enabled when some type starts to be parsed (TParser.ParseInterfaceSection)
-	Parsing of attributes is disabled when new type identifier is found and type definition is expected (TParser.ParseType)
-	When attribute is possible, it is extracted by TParser.PeekNextToken. When identifier is found, there can be no attribute, so checking is disabled until next semicolon. When attribute is possible, left square bracket is checked. If found, tokens until next right squate bracket are taken as attribute.
-	When members of class, interface or object are analysed, it is supposed that attribute can be just in front of keyword or identifier, so checking is enabled at the beginning, token is taken and attributes checking is disabled again (TParser.ParseCioMembers). When end directive occurs (end of CIO), attributes, even if found and not used, are cleared.
-	Also when CIO type declaration is parsed, parsing of attributes is enabled at the beginning, token is taken and parsing of attributes is disabled. When CIO is found, founf attributes are moved to Attributes field of TPasCio. (TParser.ParseCioTypeDecl)
-	Internal types of CIO are not parsed for attributes at this moment!!!  Should it be added?


----------------------------------------------------------------------

>Comment By: Michalis Kamburelis (kambi)
Date: 2012-02-15 14:41

Message:
Closed (implemented) by VCejka patch in "[ pasdoc-Patches-3487782 ] Support
for attributes".

----------------------------------------------------------------------

Comment By: Michalis Kamburelis (kambi)
Date: 2012-02-07 04:13

Message:
On the other hand, it's a feature request, so it's probably better to leave
it open :) In any case, I understand that you're volunteering to send a
patch for this some day soon :)

Oh, and as for FPC: I don't think FPC can parse Delphi 2010 attributes now.
PasDoc source code of course must be compileable by FPC (as well as
Delphi), but don't worry about it if you don't want to. I use FPC and will
fix eventual incompatibilities.

----------------------------------------------------------------------

Comment By: Michalis Kamburelis (kambi)
Date: 2012-02-07 04:07

Message:
From a quick reading, everything seems sensible, you're most welcome to
work on it and I'll apply :) Note that it's better to discuss stuff on a
maling list (https://lists.sourceforge.net/lists/listinfo/pasdoc-main ),
tracker should be used for things that can eventually be closed as "done".
I currently close this issue (although you can still post comments and
reopen it), as there's nothing for me to do here :)

As for:
> Internal types of CIO are not parsed for attributes at this moment!!!
Should it be added?

Internal types are parsed and handled in SVN version of PasDoc, thanks to
Arno Garrels. For example, this works:
https://pasdoc.svn.sourceforge.net/svnroot/pasdoc/trunk/tests/ok_nested_types.pas
. You should definitely prepare your patches against SVN version of the
pasdoc source code. Instructions for SVN on main www page,
http://pasdoc.sipsolutions.net/ , basically just "svn co
https://pasdoc.svn.sourceforge.net/svnroot/pasdoc/trunk".

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=354213&aid=3485296&group_id=4213

[Pasdoc-main] [ pasdoc-Patches-3487782 ] Support for attributes

[SourceForge.net <no...@so...>]

Patches item #3487782, was opened at 2012-02-15 01:00
Message generated for change (Tracker Item Submitted) made by vcejka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=304213&aid=3487782&group_id=4213

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: VCejka (vcejka)
Assigned to: Nobody/Anonymous (nobody)
Summary: Support for attributes

Initial Comment:
Attributes were added to Delphi since v2010, but their present in the source code caused PasDoc to fail. This patch adds support for finding them and generate their documentation in HTML generator.
Attributes are quite complex and their syntax can be easily mixed with other pascal syntax elements, like enumeration. I tested them on some medium scale project (<100 units), but still I'm not sure if I chekced everything. So if you find some bug, please make a report and contact me.
Suppose this patch as a beta release. If it will be accepted, support for other generators etc. can be added.
Because of generator, there should be update of language files preformed for "Attributes" string.

There is a list of souce code modification with short explanation of implementation:

Changes to PasDoc:

Items:
-	To TPasItem added property Attributes as TStringPairVector containing list of attributes defined for this item. Name property containt attribute class name, Value property contains parameters. Method SetAttributes is added, it assigns given string pair vector to PasItem and creates new one returning it back in var param

Parser:
-	added private boolean field AttributeIsPossible to Tparser
-	added private field CurrentAttributes (TStringPairVector) to Tparser, created in constructor and destroyed in destructor
-	Attributes are found in square brackets before item. If parser finds them, stores them to CurrentAttributes field and then moves them to Attributes property of appropriate TPasItem
-	Detected attributes:
o	Of constructor, destructor, function or procedure of class or record – in ParseCDFP, set to TPasMethod
o	Of Constant – in ParseConstant, set to TPasConstant
o	Of Enum – in ParseEnum, set to TPasEnum
o	Of property of class or record – in ParseProperty, set to TPasProperty
o	Of case field of class or record – in ParseRecordCase, set to TPasFieldVariable
o	Of field of class or record – in ParseFieldsVariables, set to TpasFieldVariable
o	Of class or record declaration – in ParseCioTypeDecl, set to TPasCio
o	Of any type – in ParseType, set to TPasType
-	in current Delphi implementation Constants cannot have attributes defined, but parser handles it
-	it is not possible to apply attributes to variant cases of record fields, so parsing is temporalily disabled and then restored to original state (TParser.ParseRecordCase).
-	Parsing of attributes is disabled when interface section of some unit is entered and enabled when some type keyword occurs (TParser.ParseInterfaceSection)
-	Parsing of attributes is disabled when new type identifier is found and type definition is expected (TParser.ParseType), but it is enabled again when identifier declaration is parsed (TParser.ParseInterfaceSection)
-	Parsing of attributes is temporalily disabled when skipping declaration (TParser.SkipDeclaration)
-	When attribute is possible, it is extracted by TParser.PeekNextToken. When identifier is found, there can be no attribute, so checking is disabled until next semicolon. When attribute is possible, left square bracket is checked. If found, tokens until next right squate bracket are taken as attribute. There might be square brackets as part of attribute parameres, i.e. sets, so inner brackets are ignored. There can be more attributes defined in 1 pair of square brackets, separated by comma, but comma can also separate parameters of attribute. When comma is used inside parenthesis, it is understood as parameter separator, otherwise it is used as attribute separator.
-	When members of class, interface or object are analysed, it is supposed that attribute can be just in front of keyword or identifier, so checking is enabled at the beginning, token is taken and attributes checking is disabled again (TParser.ParseCioMembers). When end directive occurs (end of CIO), attributes, even if found and not used, are cleared.
-	Also when CIO type declaration is parsed, parsing of attributes is enabled at the beginning, token is taken and parsing of attributes is disabled.
-	Internal types of CIO are not parsed for attributes at this moment!!!  Should it be added?
-	When square bratcket is found in TParser.PeekNextToken but string follows instead of identifier, it is not supposed to be attribute, but GUID. It is also added as attribute with fake attribute class name GUID

GetHtml:
-	Added WriteAttributes procedure to TGenericHTMLDocGenerator .WriteItemLongDescription

Languages:
-	added item trAttributes to TtranslationID enumeration. Translation must be added to lang/*.inc files, added to english and czech translation files, all other set to „ToDo“ string
-	style „attributes“ can be added to *.css for HTMLDocGenerator


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=304213&aid=3487782&group_id=4213

[Pasdoc-main] [ pasdoc-Patches-3485263 ] Added support for HelpInsight style comments

[SourceForge.net <no...@so...>]

Patches item #3485263, was opened at 2012-02-07 01:54
Message generated for change (Comment added) made by kambi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=304213&aid=3485263&group_id=4213

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: VCejka (vcejka)
Assigned to: Michalis Kamburelis (kambi)
Summary: Added support for HelpInsight style comments

Initial Comment:
Support for Delphi /MS VS style somments in form /// <tag> comment </tag> added. Internally they are translated to pasdoc tags. Tags supported in this version (see TParser.ExpandHelpInsightDescriptions):
summary ->@abstract
param -> @param
returns -> returns
exception -> @raises
permission -> @permission
c -> @code
code -> @preformatted
b -> @bold
i -> @italic
u -> @underline
br -> @br
ul -> @unorderedList
ol -> @orderedList
li -> @item
remark -> plain text
remarks -> plain text
comment -> plain text

New token type TOK_COMMENT_HELPINSIGHT added to PasDoc_Tokeniker.TTokenType, and also corresponding TOKEN_TYPE_NAMES string and TokenCommentTypes set member. Detection of new comment style is added to TTokenizer.ReadCommentType3, translation is launched from TParser.GetLastComment.


----------------------------------------------------------------------

>Comment By: Michalis Kamburelis (kambi)
Date: 2012-02-08 01:53

Message:
Applied, thank you for the patch!

See the latest SVN source code (trunk). Your patch was applied in revision
1308. I added note to ChangeLog. (Say your full name, or fill it in
SourceForge account, if you want me to change the "(by VCejka)" to use your
full name :)

- Documented on http://pasdoc.sipsolutions.net/WritingDocumentation
- Added testcase tests/ok_helpinsight_comments.pas, it's HTML output is
visible here:
http://pasdoc.sourceforge.net/correct_tests_output/html/ok_helpinsight_comments/ok_helpinsight_comments.html

I adjusted regexp code to use FPC's RegExpr unit (in FPC >= 2.6.0). Delphi
code (under $ifndef FPC) should work the same (but please check, as I do
not own Delphi).

A little problem was found by testsuite: you replace always, even when
author didn't use /// comment. Consider code like this:

  { Returns HTML line break, <br>. }
  function LibeBreak: string;

  { My docs. @html(Some text using HTML tags<br>blah blah<br>) }
  procedure Foo;

In both these cases, <br> *must not* be replaced with @br. The general rule
in pasdoc comments is that < and > do not have any special meaning (only @
is special), this must not be broken in comments not using ///. I fixed it
already (in SVN revision 1310) by LastCommentHelpInsight variable, and
ExpandHelpInsightDescriptions is only run when LastCommentHelpInsight =
true.


----------------------------------------------------------------------

Comment By: VCejka (vcejka)
Date: 2012-02-07 03:40

Message:
Thank you very much for such fast answer. You are right with regular
expressions. I'm not using FPC, so I'm not used thinking about that.

----------------------------------------------------------------------

Comment By: Michalis Kamburelis (kambi)
Date: 2012-02-07 02:49

Message:
I forgot to add: I will actually test it and adjust to FPC and apply
tomorrow.

----------------------------------------------------------------------

Comment By: Michalis Kamburelis (kambi)
Date: 2012-02-07 02:47

Message:
Thank you. I quickly looked at the patch, looks very clean and should apply
without any problems. The only small thing that will have to be fixed is to
replace RegularExpressions unit and class with FPC equivalent under {$ifdef
FPC}, I can take care of it.

I understand the official docs about this feature are here:
http://delphi.wikia.com/wiki/Help_insight .

I'm not sure do I like implementing this using regular expressions, but
it's certainly much shorter and simpler than anything I can otherwise
propose now :)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=304213&aid=3485263&group_id=4213

[Pasdoc-main] [ pasdoc-Feature Requests-3485296 ] attributes support

[SourceForge.net <no...@so...>]

Feature Requests item #3485296, was opened at 2012-02-07 03:44
Message generated for change (Comment added) made by kambi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=354213&aid=3485296&group_id=4213

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: VCejka (vcejka)
Assigned to: Nobody/Anonymous (nobody)
Summary: attributes support

Initial Comment:
I'm working on support for attributes added to Delphi at version 2010. I need it, because parser fails when some attribute is found. It is not finished yet, but I have no experience with FPC. If someone has some idea or demand, please post it.

Here are my current notes on implementation:
Changes to PasDoc:

Tokenizer:
-	added token Attribute + token string
-	defined constant AttributeStart + AttributeEnd ([])

Items:
-	To TPasItem added property Attributes as TstringVector containing list of attributes defined for this item. It is created in constructor and destroyed in destructor

Parser:
-	added private boolean field AttributeIsPossible to Tparser
-	added private field CurrentAttributes (TstringVector) to Tparser, created in constructor and destroyed in destructor
-	Attributes are found in square brackets before item. If parser finds them, stores them to CurrentAttributes field.
-	Once some attributes is defined when CDFP is analyzed, it is moved from CurrentAtributes to Attributes field of TPasMethod in TParser.ParseCDFP
-	Once some attributes is defined when Constant is analyzed, it is moved from CurrentAtributes to Attributes field of TPasConstant in TParser.ParseConstant
-	Once some attributes is defined when Enum is analyzed, it is moved from CurrentAtributes to Attributes field of TPasEnum in TParser.ParseEnum
-	Once some attributes is defined when Property is analyzed, it is moved from CurrentAtributes to Attributes field of TPasProperty in TParser.ParseProperty
-	Once some attributes is defined when some field of some record is analyzed, it is moved from CurrentAtributes to Attributes field of TPasFieldVariable in TParser.ParseRecordCase, but it is not possible to apply attributes to cases of record fields.
-	Once some attributes is defined when type is analyzed, it is moved from CurrentAtributes to Attributes field of TPasType in TParser.ParseType
-	Once some attributes is defined when field of class or record is analyzed, it is moved from CurrentAtributes to Attributes field of TPasFieldVariable in TParser. ParseFieldsVariables
-	Parsing of attributes is disabled when interface section of some unit is entered and enabled when some type starts to be parsed (TParser.ParseInterfaceSection)
-	Parsing of attributes is disabled when new type identifier is found and type definition is expected (TParser.ParseType)
-	When attribute is possible, it is extracted by TParser.PeekNextToken. When identifier is found, there can be no attribute, so checking is disabled until next semicolon. When attribute is possible, left square bracket is checked. If found, tokens until next right squate bracket are taken as attribute.
-	When members of class, interface or object are analysed, it is supposed that attribute can be just in front of keyword or identifier, so checking is enabled at the beginning, token is taken and attributes checking is disabled again (TParser.ParseCioMembers). When end directive occurs (end of CIO), attributes, even if found and not used, are cleared.
-	Also when CIO type declaration is parsed, parsing of attributes is enabled at the beginning, token is taken and parsing of attributes is disabled. When CIO is found, founf attributes are moved to Attributes field of TPasCio. (TParser.ParseCioTypeDecl)
-	Internal types of CIO are not parsed for attributes at this moment!!!  Should it be added?


----------------------------------------------------------------------

>Comment By: Michalis Kamburelis (kambi)
Date: 2012-02-07 04:13

Message:
On the other hand, it's a feature request, so it's probably better to leave
it open :) In any case, I understand that you're volunteering to send a
patch for this some day soon :)

Oh, and as for FPC: I don't think FPC can parse Delphi 2010 attributes now.
PasDoc source code of course must be compileable by FPC (as well as
Delphi), but don't worry about it if you don't want to. I use FPC and will
fix eventual incompatibilities.

----------------------------------------------------------------------

Comment By: Michalis Kamburelis (kambi)
Date: 2012-02-07 04:07

Message:
From a quick reading, everything seems sensible, you're most welcome to
work on it and I'll apply :) Note that it's better to discuss stuff on a
maling list (https://lists.sourceforge.net/lists/listinfo/pasdoc-main ),
tracker should be used for things that can eventually be closed as "done".
I currently close this issue (although you can still post comments and
reopen it), as there's nothing for me to do here :)

As for:
> Internal types of CIO are not parsed for attributes at this moment!!!
Should it be added?

Internal types are parsed and handled in SVN version of PasDoc, thanks to
Arno Garrels. For example, this works:
https://pasdoc.svn.sourceforge.net/svnroot/pasdoc/trunk/tests/ok_nested_types.pas
. You should definitely prepare your patches against SVN version of the
pasdoc source code. Instructions for SVN on main www page,
http://pasdoc.sipsolutions.net/ , basically just "svn co
https://pasdoc.svn.sourceforge.net/svnroot/pasdoc/trunk".

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=354213&aid=3485296&group_id=4213

[Pasdoc-main] [ pasdoc-Feature Requests-3485296 ] attributes support

[SourceForge.net <no...@so...>]

Feature Requests item #3485296, was opened at 2012-02-07 03:44
Message generated for change (Comment added) made by kambi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=354213&aid=3485296&group_id=4213

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: VCejka (vcejka)
Assigned to: Nobody/Anonymous (nobody)
Summary: attributes support

Initial Comment:
I'm working on support for attributes added to Delphi at version 2010. I need it, because parser fails when some attribute is found. It is not finished yet, but I have no experience with FPC. If someone has some idea or demand, please post it.

Here are my current notes on implementation:
Changes to PasDoc:

Tokenizer:
-	added token Attribute + token string
-	defined constant AttributeStart + AttributeEnd ([])

Items:
-	To TPasItem added property Attributes as TstringVector containing list of attributes defined for this item. It is created in constructor and destroyed in destructor

Parser:
-	added private boolean field AttributeIsPossible to Tparser
-	added private field CurrentAttributes (TstringVector) to Tparser, created in constructor and destroyed in destructor
-	Attributes are found in square brackets before item. If parser finds them, stores them to CurrentAttributes field.
-	Once some attributes is defined when CDFP is analyzed, it is moved from CurrentAtributes to Attributes field of TPasMethod in TParser.ParseCDFP
-	Once some attributes is defined when Constant is analyzed, it is moved from CurrentAtributes to Attributes field of TPasConstant in TParser.ParseConstant
-	Once some attributes is defined when Enum is analyzed, it is moved from CurrentAtributes to Attributes field of TPasEnum in TParser.ParseEnum
-	Once some attributes is defined when Property is analyzed, it is moved from CurrentAtributes to Attributes field of TPasProperty in TParser.ParseProperty
-	Once some attributes is defined when some field of some record is analyzed, it is moved from CurrentAtributes to Attributes field of TPasFieldVariable in TParser.ParseRecordCase, but it is not possible to apply attributes to cases of record fields.
-	Once some attributes is defined when type is analyzed, it is moved from CurrentAtributes to Attributes field of TPasType in TParser.ParseType
-	Once some attributes is defined when field of class or record is analyzed, it is moved from CurrentAtributes to Attributes field of TPasFieldVariable in TParser. ParseFieldsVariables
-	Parsing of attributes is disabled when interface section of some unit is entered and enabled when some type starts to be parsed (TParser.ParseInterfaceSection)
-	Parsing of attributes is disabled when new type identifier is found and type definition is expected (TParser.ParseType)
-	When attribute is possible, it is extracted by TParser.PeekNextToken. When identifier is found, there can be no attribute, so checking is disabled until next semicolon. When attribute is possible, left square bracket is checked. If found, tokens until next right squate bracket are taken as attribute.
-	When members of class, interface or object are analysed, it is supposed that attribute can be just in front of keyword or identifier, so checking is enabled at the beginning, token is taken and attributes checking is disabled again (TParser.ParseCioMembers). When end directive occurs (end of CIO), attributes, even if found and not used, are cleared.
-	Also when CIO type declaration is parsed, parsing of attributes is enabled at the beginning, token is taken and parsing of attributes is disabled. When CIO is found, founf attributes are moved to Attributes field of TPasCio. (TParser.ParseCioTypeDecl)
-	Internal types of CIO are not parsed for attributes at this moment!!!  Should it be added?


----------------------------------------------------------------------

>Comment By: Michalis Kamburelis (kambi)
Date: 2012-02-07 04:07

Message:
From a quick reading, everything seems sensible, you're most welcome to
work on it and I'll apply :) Note that it's better to discuss stuff on a
maling list (https://lists.sourceforge.net/lists/listinfo/pasdoc-main ),
tracker should be used for things that can eventually be closed as "done".
I currently close this issue (although you can still post comments and
reopen it), as there's nothing for me to do here :)

As for:
> Internal types of CIO are not parsed for attributes at this moment!!!
Should it be added?

Internal types are parsed and handled in SVN version of PasDoc, thanks to
Arno Garrels. For example, this works:
https://pasdoc.svn.sourceforge.net/svnroot/pasdoc/trunk/tests/ok_nested_types.pas
. You should definitely prepare your patches against SVN version of the
pasdoc source code. Instructions for SVN on main www page,
http://pasdoc.sipsolutions.net/ , basically just "svn co
https://pasdoc.svn.sourceforge.net/svnroot/pasdoc/trunk".

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=354213&aid=3485296&group_id=4213

[Pasdoc-main] [ pasdoc-Feature Requests-3485296 ] attributes support

[SourceForge.net <no...@so...>]

Feature Requests item #3485296, was opened at 2012-02-07 03:44
Message generated for change (Tracker Item Submitted) made by vcejka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=354213&aid=3485296&group_id=4213

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: VCejka (vcejka)
Assigned to: Nobody/Anonymous (nobody)
Summary: attributes support

Initial Comment:
I'm working on support for attributes added to Delphi at version 2010. I need it, because parser fails when some attribute is found. It is not finished yet, but I have no experience with FPC. If someone has some idea or demand, please post it.

Here are my current notes on implementation:
Changes to PasDoc:

Tokenizer:
-	added token Attribute + token string
-	defined constant AttributeStart + AttributeEnd ([])

Items:
-	To TPasItem added property Attributes as TstringVector containing list of attributes defined for this item. It is created in constructor and destroyed in destructor

Parser:
-	added private boolean field AttributeIsPossible to Tparser
-	added private field CurrentAttributes (TstringVector) to Tparser, created in constructor and destroyed in destructor
-	Attributes are found in square brackets before item. If parser finds them, stores them to CurrentAttributes field.
-	Once some attributes is defined when CDFP is analyzed, it is moved from CurrentAtributes to Attributes field of TPasMethod in TParser.ParseCDFP
-	Once some attributes is defined when Constant is analyzed, it is moved from CurrentAtributes to Attributes field of TPasConstant in TParser.ParseConstant
-	Once some attributes is defined when Enum is analyzed, it is moved from CurrentAtributes to Attributes field of TPasEnum in TParser.ParseEnum
-	Once some attributes is defined when Property is analyzed, it is moved from CurrentAtributes to Attributes field of TPasProperty in TParser.ParseProperty
-	Once some attributes is defined when some field of some record is analyzed, it is moved from CurrentAtributes to Attributes field of TPasFieldVariable in TParser.ParseRecordCase, but it is not possible to apply attributes to cases of record fields.
-	Once some attributes is defined when type is analyzed, it is moved from CurrentAtributes to Attributes field of TPasType in TParser.ParseType
-	Once some attributes is defined when field of class or record is analyzed, it is moved from CurrentAtributes to Attributes field of TPasFieldVariable in TParser. ParseFieldsVariables
-	Parsing of attributes is disabled when interface section of some unit is entered and enabled when some type starts to be parsed (TParser.ParseInterfaceSection)
-	Parsing of attributes is disabled when new type identifier is found and type definition is expected (TParser.ParseType)
-	When attribute is possible, it is extracted by TParser.PeekNextToken. When identifier is found, there can be no attribute, so checking is disabled until next semicolon. When attribute is possible, left square bracket is checked. If found, tokens until next right squate bracket are taken as attribute.
-	When members of class, interface or object are analysed, it is supposed that attribute can be just in front of keyword or identifier, so checking is enabled at the beginning, token is taken and attributes checking is disabled again (TParser.ParseCioMembers). When end directive occurs (end of CIO), attributes, even if found and not used, are cleared.
-	Also when CIO type declaration is parsed, parsing of attributes is enabled at the beginning, token is taken and parsing of attributes is disabled. When CIO is found, founf attributes are moved to Attributes field of TPasCio. (TParser.ParseCioTypeDecl)
-	Internal types of CIO are not parsed for attributes at this moment!!!  Should it be added?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=354213&aid=3485296&group_id=4213

[Pasdoc-main] [ pasdoc-Patches-3485263 ] Added support for HelpInsight style comments

[SourceForge.net <no...@so...>]

Patches item #3485263, was opened at 2012-02-07 01:54
Message generated for change (Comment added) made by kambi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=304213&aid=3485263&group_id=4213

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: VCejka (vcejka)
Assigned to: Michalis Kamburelis (kambi)
Summary: Added support for HelpInsight style comments

Initial Comment:
Support for Delphi /MS VS style somments in form /// <tag> comment </tag> added. Internally they are translated to pasdoc tags. Tags supported in this version (see TParser.ExpandHelpInsightDescriptions):
summary ->@abstract
param -> @param
returns -> returns
exception -> @raises
permission -> @permission
c -> @code
code -> @preformatted
b -> @bold
i -> @italic
u -> @underline
br -> @br
ul -> @unorderedList
ol -> @orderedList
li -> @item
remark -> plain text
remarks -> plain text
comment -> plain text

New token type TOK_COMMENT_HELPINSIGHT added to PasDoc_Tokeniker.TTokenType, and also corresponding TOKEN_TYPE_NAMES string and TokenCommentTypes set member. Detection of new comment style is added to TTokenizer.ReadCommentType3, translation is launched from TParser.GetLastComment.


----------------------------------------------------------------------

>Comment By: Michalis Kamburelis (kambi)
Date: 2012-02-07 02:49

Message:
I forgot to add: I will actually test it and adjust to FPC and apply
tomorrow.

----------------------------------------------------------------------

Comment By: Michalis Kamburelis (kambi)
Date: 2012-02-07 02:47

Message:
Thank you. I quickly looked at the patch, looks very clean and should apply
without any problems. The only small thing that will have to be fixed is to
replace RegularExpressions unit and class with FPC equivalent under {$ifdef
FPC}, I can take care of it.

I understand the official docs about this feature are here:
http://delphi.wikia.com/wiki/Help_insight .

I'm not sure do I like implementing this using regular expressions, but
it's certainly much shorter and simpler than anything I can otherwise
propose now :)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=304213&aid=3485263&group_id=4213

[Pasdoc-main] [ pasdoc-Patches-3485263 ] Added support for HelpInsight style comments

[SourceForge.net <no...@so...>]

Patches item #3485263, was opened at 2012-02-07 01:54
Message generated for change (Comment added) made by kambi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=304213&aid=3485263&group_id=4213

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: VCejka (vcejka)
>Assigned to: Michalis Kamburelis (kambi)
Summary: Added support for HelpInsight style comments

Initial Comment:
Support for Delphi /MS VS style somments in form /// <tag> comment </tag> added. Internally they are translated to pasdoc tags. Tags supported in this version (see TParser.ExpandHelpInsightDescriptions):
summary ->@abstract
param -> @param
returns -> returns
exception -> @raises
permission -> @permission
c -> @code
code -> @preformatted
b -> @bold
i -> @italic
u -> @underline
br -> @br
ul -> @unorderedList
ol -> @orderedList
li -> @item
remark -> plain text
remarks -> plain text
comment -> plain text

New token type TOK_COMMENT_HELPINSIGHT added to PasDoc_Tokeniker.TTokenType, and also corresponding TOKEN_TYPE_NAMES string and TokenCommentTypes set member. Detection of new comment style is added to TTokenizer.ReadCommentType3, translation is launched from TParser.GetLastComment.


----------------------------------------------------------------------

>Comment By: Michalis Kamburelis (kambi)
Date: 2012-02-07 02:47

Message:
Thank you. I quickly looked at the patch, looks very clean and should apply
without any problems. The only small thing that will have to be fixed is to
replace RegularExpressions unit and class with FPC equivalent under {$ifdef
FPC}, I can take care of it.

I understand the official docs about this feature are here:
http://delphi.wikia.com/wiki/Help_insight .

I'm not sure do I like implementing this using regular expressions, but
it's certainly much shorter and simpler than anything I can otherwise
propose now :)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=304213&aid=3485263&group_id=4213

[Pasdoc-main] [ pasdoc-Patches-3485263 ] Added support for HelpInsight style comments

[SourceForge.net <no...@so...>]

Patches item #3485263, was opened at 2012-02-07 01:54
Message generated for change (Tracker Item Submitted) made by vcejka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=304213&aid=3485263&group_id=4213

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: VCejka (vcejka)
Assigned to: Nobody/Anonymous (nobody)
Summary: Added support for HelpInsight style comments

Initial Comment:
Support for Delphi /MS VS style somments in form /// <tag> comment </tag> added. Internally they are translated to pasdoc tags. Tags supported in this version (see TParser.ExpandHelpInsightDescriptions):
summary ->@abstract
param -> @param
returns -> returns
exception -> @raises
permission -> @permission
c -> @code
code -> @preformatted
b -> @bold
i -> @italic
u -> @underline
br -> @br
ul -> @unorderedList
ol -> @orderedList
li -> @item
remark -> plain text
remarks -> plain text
comment -> plain text

New token type TOK_COMMENT_HELPINSIGHT added to PasDoc_Tokeniker.TTokenType, and also corresponding TOKEN_TYPE_NAMES string and TokenCommentTypes set member. Detection of new comment style is added to TTokenizer.ReadCommentType3, translation is launched from TParser.GetLastComment.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=304213&aid=3485263&group_id=4213

Re: [Pasdoc-main] PasDoc handles now generics (both FPC and Delphi flavor) nicely

[Michalis K. <mic...@gm...>]

Noah Silva wrote:
> (I am kind-of hoping they escape the
> only unit they are in now and become more common before I feel safe using
> them everywhere).

Current FPC in SVN has a little more generics usage, besides FGL unit:
- there is fcl-stl package (with various containers designed similar
to C++ STL).
- inside Classes unit there is a define FPC_TESTGENERICS that makes
some standard things use generics (TFPList, which in turn is used by
many other containers, and TFPStrObjMap, which in turn is used by
TStringList).

I hope too that generics usage will spread more widely through FPC and
Lazarus sources :) Anyway, they are already quite capable in my
experience (in my engine, I use generics a lot --- 71 descendants of
FGL.TFPGObjectList, 9 descendants of TFPGList, 56 descendants of my
own TGenericStructList, and everything works nicely :) Previously I
was using hand-made templates.

Michalis

Re: [Pasdoc-main] PasDoc handles now generics (both FPC and Delphi flavor) nicely

[Noah S. <sh...@ga...>]

Hi,

I haven't used generics too heavily in FPC yet, but it's nice to know they
are being handled properly in PasDoc.  (I am kind-of hoping they escape the
only unit they are in now and become more common before I feel safe using
them everywhere).

Thank you,
   Noah Silva

2011/8/8 Michalis Kamburelis <mic...@gm...>

> Hi,
>
> I recently converted my game engine to heavily use FPC generics, so of
> course I needed PasDoc to properly support them too :) Done. Both FPC
> and Delphi generics flavor is now fully handled by PasDoc as far as I
> know. Both specialization of generics, and declaring generic classes,
> work.
>
> Also, hierarchy of FPC FGL containers (TFPSList, TFPGList and friends)
> is added to the default knowledge of PasDoc "external classes
> hierarchy", so they'll show up nicely in "Class Hierarchy" diagrams
> too.
>
> The whole thing was tested on (much extended now) tests/ok_generic.pas
> (and my sources).
>
> There are of course little things to improve (the types on type
> identifiers list "<T1,T2>", could be parsed better and added to the
> internal types of the class; OTOH, they will have to be treated
> specially anyway, as these types are not defined at the generic
> declaration --- that's the whole point of generics, after all). But I
> think that the result looks acceptable already :)
>
> Enjoy :),
> Michalis
>
>
> ------------------------------------------------------------------------------
> BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
> The must-attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
> _______________________________________________
> Pasdoc-main mailing list
> Pas...@li...
> https://lists.sourceforge.net/lists/listinfo/pasdoc-main
>

[Pasdoc-main] PasDoc wiki protection from spammers

[Michalis K. <mic...@gm...>]

Hi,

As you may have noticed, our wiki was being hit a lot by spammers
recently. I was patiently reverting every day the spam (and adding it
to LocalBadContent), but with a couple of new spam links every day
this simply stopped working --- too often some important wiki page was
temporarily replaced by a useless spam. And our "recent changes" page
stopped being useful (99% of the time it only shows some people
spamming, and me reverting it).

I still very much want to keep the wiki editable by anonymous, so I
don't want to just limit editing to registered users, not to mention
to some hand-picked users. As long as it's possible.

Thanks to Johannes Berg, maintainer of our wiki server (and former
long-time maintainer of our project :), we now have a simple solution
(advised by MoinMoin developers): TextCha. You will be greeted by a
trivial question on each edit. You will have to answer it, otherwise
the edit will be rejected. You can go on and try editing some wiki
page now; the answer to the question is hopefully obvious to everyone
here :) But hopefully the spammers will not even bother trying.

I don't think this is too bothersome, but still: a few usernames on
the wiki that I remember as being developers/contributors are part of
the TrustedUsersGroup,
http://pasdoc.sipsolutions.net/TrustedUsersGroup , and you are
excluded from this check.

Michalis

[Pasdoc-main] PasDoc handles now generics (both FPC and Delphi flavor) nicely

[Michalis K. <mic...@gm...>]

Hi,

I recently converted my game engine to heavily use FPC generics, so of
course I needed PasDoc to properly support them too :) Done. Both FPC
and Delphi generics flavor is now fully handled by PasDoc as far as I
know. Both specialization of generics, and declaring generic classes,
work.

Also, hierarchy of FPC FGL containers (TFPSList, TFPGList and friends)
is added to the default knowledge of PasDoc "external classes
hierarchy", so they'll show up nicely in "Class Hierarchy" diagrams
too.

The whole thing was tested on (much extended now) tests/ok_generic.pas
(and my sources).

There are of course little things to improve (the types on type
identifiers list "<T1,T2>", could be parsed better and added to the
internal types of the class; OTOH, they will have to be treated
specially anyway, as these types are not defined at the generic
declaration --- that's the whole point of generics, after all). But I
think that the result looks acceptable already :)

Enjoy :),
Michalis

[Pasdoc-main] [ pasdoc-Bugs-2500102 ] Error when parsing Delphi 2009 files with generics

[SourceForge.net <no...@so...>]

Bugs item #2500102, was opened at 2009-01-11 23:43
Message generated for change (Comment added) made by kambi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104213&aid=2500102&group_id=4213

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: parser (Delphi 200x features)
Group: 0.11.0
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Michalis Kamburelis (kambi)
Summary: Error when parsing Delphi 2009 files with generics

Initial Comment:
In Delphi 2009, Generics where introduced using a syntax like

type
 TMyList = TObjectList<MyClass>

This creates an TObjectList descendant using Items of MyClass.

Also you may inherit like

type
 TMyList = class(TObjectList<MyClass>)
   {...}
  end;

Unfortunately, PasDoc ist not able to parse these files because of the "<" and ">". Therefore, the whole file is not included in the documentation. All that is needed is to treat "<" and ">" as part of the class-name. 

Hopefully, this will be fixed soon.

Thomas Hummes
tho...@gm...

----------------------------------------------------------------------

>Comment By: Michalis Kamburelis (kambi)
Date: 2011-08-08 12:27

Message:
Generics are now fully handled by PasDoc (both specialization and
declaration of generic classes). The current testcase
http://pasdoc.svn.sourceforge.net/viewvc/pasdoc/trunk/tests/ok_generic.pas
is parsed without problems :)

To try it yourself, use PasDoc from SVN, or
http://pasdoc.sipsolutions.net/DevelopmentSnapshots, or just wait for next
release.

----------------------------------------------------------------------

Comment By: Michalis Kamburelis (kambi)
Date: 2011-07-23 23:41

Message:
This is partially solved since some time. See my mail "[Pasdoc-main]
Parsing of generics specialization" on pasdoc-main mailing list,
https://sourceforge.net/mailarchive/forum.php?thread_name=4D386FD3.7060505%40gmail.com&forum_name=pasdoc-main

See also SVN commit 1290. Works for Delphi and FPC generic syntax. Our
testcase
http://pasdoc.svn.sourceforge.net/viewvc/pasdoc/trunk/tests/ok_generic.pas
includes some examples.

This works exactly like you describe, we just add "<...>" to the class
name. This isn't a fully correct solution (e.g. we will not correctly
detect later that actually ancestor is "TObjectList", not literally
"TObjectList<MyClass>"), that's why I'm leaving this bug open for now. But
at least parsing the unit with generic specialization works, and result
looks sensible.

You can test it now by compiling pasdoc from SVN or getting
http://pasdoc.sipsolutions.net/DevelopmentSnapshots

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104213&aid=2500102&group_id=4213

[Pasdoc-main] [ pasdoc-Bugs-2500102 ] Error when parsing Delphi 2009 files with generics

[SourceForge.net <no...@so...>]

Bugs item #2500102, was opened at 2009-01-11 23:43
Message generated for change (Comment added) made by kambi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104213&aid=2500102&group_id=4213

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: parser (Delphi 200x features)
Group: 0.11.0
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error when parsing Delphi 2009 files with generics

Initial Comment:
In Delphi 2009, Generics where introduced using a syntax like

type
 TMyList = TObjectList<MyClass>

This creates an TObjectList descendant using Items of MyClass.

Also you may inherit like

type
 TMyList = class(TObjectList<MyClass>)
   {...}
  end;

Unfortunately, PasDoc ist not able to parse these files because of the "<" and ">". Therefore, the whole file is not included in the documentation. All that is needed is to treat "<" and ">" as part of the class-name. 

Hopefully, this will be fixed soon.

Thomas Hummes
tho...@gm...

----------------------------------------------------------------------

>Comment By: Michalis Kamburelis (kambi)
Date: 2011-07-23 23:41

Message:
This is partially solved since some time. See my mail "[Pasdoc-main]
Parsing of generics specialization" on pasdoc-main mailing list,
https://sourceforge.net/mailarchive/forum.php?thread_name=4D386FD3.7060505%40gmail.com&forum_name=pasdoc-main

See also SVN commit 1290. Works for Delphi and FPC generic syntax. Our
testcase
http://pasdoc.svn.sourceforge.net/viewvc/pasdoc/trunk/tests/ok_generic.pas
includes some examples.

This works exactly like you describe, we just add "<...>" to the class
name. This isn't a fully correct solution (e.g. we will not correctly
detect later that actually ancestor is "TObjectList", not literally
"TObjectList<MyClass>"), that's why I'm leaving this bug open for now. But
at least parsing the unit with generic specialization works, and result
looks sensible.

You can test it now by compiling pasdoc from SVN or getting
http://pasdoc.sipsolutions.net/DevelopmentSnapshots

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104213&aid=2500102&group_id=4213

[Pasdoc-main] [ pasdoc-Bugs-2886653 ] private const

[SourceForge.net <no...@so...>]

Bugs item #2886653, was opened at 2009-10-26 20:05
Message generated for change (Comment added) made by kambi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104213&aid=2886653&group_id=4213

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: parser (Delphi 200x features)
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Grzegorz Skoczylas (gskoczylas)
Assigned to: Nobody/Anonymous (nobody)
Summary: private const

Initial Comment:
PasDoc is unable to parse constant defined in *strict private* section of class. I have tested both the PasDoc 0.11 and the PasDoc2 (checkout from the https://pasdoc.svn.sourceforge.net/svnroot/pasdoc/branches/PasDoc2).

Error is incorrectly detected in the line #56 of the attached file. This code is compiling without any hints or warnings (or errors) with Delphi 2007.

----------------------------------------------------------------------

>Comment By: Michalis Kamburelis (kambi)
Date: 2011-07-23 23:30

Message:
Quickly tested

  pasdoc --visible-members protected,public,private,strictprivate
Demo.pas

with current PasDoc from SVN, everything looks fine now :) You can compile
latest pasdoc from SVN yourself or use
http://pasdoc.sipsolutions.net/DevelopmentSnapshots to have it working for
now.

----------------------------------------------------------------------

Comment By: Dr. Diettrich (drdiettrich)
Date: 2009-10-26 23:41

Message:
Right, PasDoc cannot handle private constants nor types.

Can you provide a grammar for the current OPL?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104213&aid=2886653&group_id=4213

[Pasdoc-main] [ pasdoc-Bugs-3101524 ] Somtimes log contains strage characters

[SourceForge.net <no...@so...>]

Bugs item #3101524, was opened at 2010-11-02 12:34
Message generated for change (Comment added) made by kambi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104213&aid=3101524&group_id=4213

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: 0.12.0
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Michalis Kamburelis (kambi)
Summary: Somtimes log contains strage characters

Initial Comment:
I'm using PasDoc for creating either HTML or CHM documentation. Whem I'm creating HTML documentation, the PasDoc's log is correct. But when I'm creating CHM documentation, then log contains strange characers.

My commandline for HTML documentation:
P:\PasDoc\bin\pasdoc.exe --include=. --output p:\Huzar\Doc\doc\ --write-uses-list --title "Huzar Tools" --use-tipue-search --marker : --language pl.cp1250 --format html --full-link --cache-dir p:\Huzar\Doc\doc.cache --implicit-visibility implicit --graphviz-classes --link-gv-classes png *.pas >pasdoc.log

My commandline for CHM documentation:
P:\PasDoc\bin\pasdoc.exe --include=. --output p:\Huzar\Doc\chm\ --write-uses-list --title "Huzar Tools" --use-tipue-search --marker : --language pl.cp1250 --format htmlhelp --full-link --cache-dir p:\Huzar\Doc\chm.cache --name "Huzar Software" --implicit-visibility implicit --graphviz-classes --link-gv-classes png *.pas >pasdoc.log



----------------------------------------------------------------------

>Comment By: Michalis Kamburelis (kambi)
Date: 2011-07-23 23:19

Message:
Ups, this bug should be closed since a long time (0.12.1 release). Closing
now.

----------------------------------------------------------------------

Comment By: Grzegorz Skoczylas (gskoczylas)
Date: 2010-11-03 23:55

Message:
Please ignore my previous comment. I did not notice that it is already
implemented in PasDoc 0.12.1.

----------------------------------------------------------------------

Comment By: Grzegorz Skoczylas (gskoczylas)
Date: 2010-11-03 23:50

Message:
Maybe a good solution would be to add a version identifier to the cache
file. If the version identifier read from the cache file would be different
from the version of the PasDoc, such a cache file would automatically be
regarded as outdated.

----------------------------------------------------------------------

Comment By: Michalis Kamburelis (kambi)
Date: 2010-11-03 16:48

Message:
With new PasDoc 0.12.1, the cache files from the old PasDoc version will be
automatically detected and overridden.

----------------------------------------------------------------------

Comment By: Michalis Kamburelis (kambi)
Date: 2010-11-02 17:27

Message:
Looking more carefully at your command-line, I realized that you use
different cache directories for html and htmlhelp: 
- p:\Huzar\Doc\doc.cache for html
- p:\Huzar\Doc\chm.cache for htmlhelp

This is not needed (you can use the same cache directory for various
output formats, it's guaranteed to work Ok. It's even adviced, to take most
advantage of cache speedup).

This also kind-of confirms my previous suggestion. Inside
p:\Huzar\Doc\chm.cache you probably have old cache files, from previous
pasdoc version. You should remove them. Your html cache uses different
directory, that seemingly had no old cache files.

----------------------------------------------------------------------

Comment By: Michalis Kamburelis (kambi)
Date: 2010-11-02 12:51

Message:
Hm, the strange characters in log appear because you have strange content
in your cache files. The real problem is that our cache reading fails, with
"Warning[2]: Error ESerializedException: Tried loading unknown class"
(followed by a nonsense class name with strange characters).

Do you maybe have cache files from older PasDoc version inside
p:\Huzar\Doc\doc.cache? If yes, then you should delete them. Cache files
between PasDoc releases are incompatible. It may be a pure coincidence that
html generation succeeds without any strange errors. (Admittedly, we should
resolve it better, by placing a nice version marker in cache files and
simply automatically handling this case in pasdoc.)

I tried your commands on PasDoc files, and evereything seems to work here,
if I start from a clear (no files) cache directory:

cd trunk/source/component/
pasdoc --include=. --output /tmp/ --write-uses-list --title "Huzar Tools"
--use-tipue-search --marker : --language pl.cp1250 --format html
--full-link --cache-dir /tmp/cache --implicit-visibility implicit
--graphviz-classes --link-gv-classes png *.pas > pasdoc.log
pasdoc --include=. --output /tmp/ --write-uses-list --title "Huzar Tools"
--use-tipue-search --marker : --language pl.cp1250 --format htmlhelp
--full-link --cache-dir /tmp/cache --name "Huzar Software"
--implicit-visibility implicit --graphviz-classes --link-gv-classes png
*.pas > pasdoc.log

So
1. try deleting all cache files from p:\Huzar\Doc\doc.cache
2. if this doesn't help, you'll have to provide your source files, so that
we can reproduce the problem. Preferably, not your full source code, but a
sample unit / part of the unit that still causes the bug.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104213&aid=3101524&group_id=4213

Re: [Pasdoc-main] PasDoc2

[Hans-Peter D. <DrD...@ao...>]

Michalis Kamburelis schrieb:
> (I changed the subject, we diverged from original Ales question here.)

> First of all, looks like we already have what we need in trunk.

Fine, why then bother about PasDoc2?

DoDi