Param style parsing for a user defined section?

[cpiker]

Hi @adamdruppe
I'm a new adrdox user so this might be a silly question. I'm looking to have adrdox parse a user defined section in a similar manner as a ddoc params: section. I think the params: style layout would look nice for documenting the type list for structure and class templates. Here's an example of what I'm going for:

/** Provides coordinates for wrapped range elements
 * This is the structure typically used to wrap `.front` elements of an InputRange to the
 * `.front` elements of a [DataRange].  It is [DataRange.font] property type, among other
 * uses.
 * 
 * Types:
 *    RT = The original InputRange type.
 *    CT = The coordinate data type.  Typically the return type of the coordinate minima,
 *         and maxima functions given to the [dataRange] function template.
 */
struct DataElement(RT, CT)){
    const ElementType!RT data;
    const CT cbeg;
    const CT cend;
}

It's quite possible that this customization case was addressed in the adrdox docs and I just overlooked it.

In general it's seemed kind of odd to me that there wasn't a standard ddoc types: section, though maybe the reason for that will become obvious over time.

[adamdruppe]

You can actually just list the types there under Params and it adds them for functions but not for structs. That's just a bug in here that was on my list but I forgot about it! Just fixed on the master branch if you wanna try a custom build, and I'll put it on the *.dpldocs.info website on the next push later.

result here: http://dpldocs.info/experimental-docs/testparams.DataElement.html

after changing Types to Params in your example.

I've also considered using that a=b syntax as one of the bracketed blocks before too, probably like $(KV_LIST) or something. I just need to refactor the code a bit to allow that and I'm lazy.

[cpiker]

Yep, after a pull and build of adrdox I can see Params sections for my structs.

Wow, that was fast! :)

[adamdruppe]

yea i've thought about this before so i knew where to look. turns out i just did something silly before and it ignored structs and classes in the hasParam function. oops.

but my general dev style too is to lay a bunch of groundwork early so when i need something, i can do it quickly enough... but i don't just do things comprehensively ahead of time. like most this week i've been doing some styling foundation for my gui library. i prolly won't finish it per se but now that all these pieces are in place, i can add new style control properties in a matter of minutes instead of hours.

but wow it is taking FOREVER to get this right. and then people expect me to dub tag things and when do i tag it when it is never done?!?!!? oh well.

[cpiker]

but wow it is taking FOREVER to get this right. and then people expect me to dub tag things and when do i tag it when it is never done?!?!!? oh well.

One developer I work with just tags everything by the calendar date about once a week, since yea, you're right, when is software done? His versions are just 20210505, 20210514, etc. It works fine. Not using semantic versioning hasn't caused the sky to cave in.

[adamdruppe]

eyah i do that in the documentation - it is all like Added May 14, 2021 but for dub i try to keep the other thing going despite it being kinda silly (and i rarely break anything anyway. ill tag 10.0 soon which implies ten breaking changes..... over 13 years among 70 modules...... but each one is usually easy. like 9.0 got tagged because a font size calculation was changed. that's it. lol)

oh well