Multiple \modules per entity?
Would it be possible to have \ingroup and \defgroup commands that are compatible with Doxygen in addition to the current \group command? This will make the transition from Doxygen to Standardese easier.
What are the Doxygen semantics for grouping?
Because my group is more like Doxygen's @{, i.e. one doc for multiple entities.
Ah, I see. So Doxygen has two types of groups. Grouping the doc for multiple entities like you had, and also having a group or "module" that has a page generated where all entities in that module are listed. The semantics are the same as what a namespace would do normally, but allows putting entities from different namespaces, and even namespaces themselves into a single module. You can see an example here if you look at Tensor, or DataBox (I'm still moving much of the other code over so not all modules are filled yet). Metal also uses the modules extensively to group together metafunctions that are for example related to manipulating lists, etc. Any entity can be assigned to multiple modules, which is useful for generic code.
Does that help?
I also have \module but an entity can only be in one module.
Ah yes, that looks to be exactly what Doxygen calls groups. Allowing an entity to be in multiple groups would be useful.
Maybe to deal with Doxygen compatibility there should be an option that defaults to no that enables and disables Doxygen compatible commands. This way people could easily test Standardese on their documentation, and then move commands over as they progress. Thoughts?
I'm not sure putting an entity in multiple modules is useful, if you can convince me, I'll do it.
Regarding compatibility: I'll never be fully compatible with Doxygen but I already do support command renaming.
I have an example of how I use an entity in multiple modules. I have a type trait used for helping out with my Tensor class, so it should be in the Tensor module here. However, I have a separate module for all type traits, which it should also be in. If I only put it in the Tensor module someone will look at Type Traits since it's technically a type trait and won't find it. If I put it in the Type Trait module someone who's working with Tensor and not thinking about type traits won't find it. The logical location for it is to be in both.
I'll have to look at the command renaming. This could be sufficient for most uses.