Hi,

I'm ready to supply the new IPF Output Writer patch for fpdoc. But how should I supply this patch, because I implemented a few extra features into the Linear Output Writer as well.

* One big patch with everything included.

or

* Patch with new IPF writer
* patch for Interfaces Overview in Linear writer
* patch with new Linear Writer specific parameter to control if linked documentation should be duplicated or not.
* patch for fixing minor spelling mistakes in fpdoc
* patch to not create a section Errors if there isn't actually any specific documentation for errors.
* patch to fix SeeAlso section in Linear writer. It never output the custom text, but always the node link as text.
* new features for linear writer that could be overridden in descendants.
- marked some protected methods as virtual
- new section for listing Types found in a unit

The problem with most of these smaller patches, other than the new IPF writer, is that they occur in the same unit. So the patches will have to be applied in some order, otherwise patch line numbers will be wrong. This is hard to do, because I used SubVersion while developing, so couldn't create smaller local commits that are feature specific.

So is it ok if I give one large patch? Alternative (and more work) is to use the git mirror repository, copy the changed units over, then I can split the patches into smaller bits. The latter is probably best, but I'm a bit lazy today. ;-)

Regards,
- Graeme -

One big patch is OK for me.

We want more patch contributions, so I definitely do not want to make it hard for people to contribute patches :-)

Michael.

Op 2010-08-17 10:57, Michael Van Canneyt het geskryf:

One big patch is OK for me.

Submitted to Mantis.

http://bugs.freepascal.org/view.php?id=17191

Michael, there is only one issue I have with fpdoc at the moment. It is regarding Marco's recent change regarding resolving links. See the following Mantis report for details.
http://bugs.freepascal.org/view.php?id=17146

If I use the code as Marco committed it, then fpGUI's class documentation works fine. All links are active and pointing to the correct places. But then RTL & FCL's IPF output links are broken. Swap them around like I did in the IPF patch (dglobals.pp line 990-995), then RTL and FCL docs links work, but fpGUI's links are broken. :-(

This only relates to links pointing to the same unit. eg: One global procedure pointing to another global procedure without referencing the unit name. eg. link format: <procedure> vs <unit>.<procedure>

I can't seem to figure out what is causing the one or the other to fail resolving links. Would you mind taking a look when you have time? Or Marco?

Regards,
- Graeme -

In our previous episode, Graeme Geldenhuys said:

If I understand it well, the code currently tries to first lookup #rtl.xxx and then #rtl.currentmodule.xxx

The problem was before a relative path could not be an unit name, or be relative to an unit name (classes.tstringlist)

So the order should only matter for identifiers that duplicate as unitnames. (and these should then be made with absolute paths, since both solution then are not safe)

Anyway, I don't see anything here that could lead to corrupt links.

p.s.
My agenda for fpdoc in the coming week:
- Make sure that inheritance data is available over package bounderies. This will make inheritance trees work over package bounderies (and does the prepatory work for interface trees too)

- reduce the noise (warnings). I suspect several of these errors are redundant because they are the result of multiple different attempts at resolving. This will probably mean a few more service routines that only issue a warning if nothing can be found using multiple means. But that is only a hunch, I still have to read up on this part of fpdoc.