lunarmodules
Allow Module Merging
Currently LDoc complains if two files declare that they are the same module. Since LDoc claims that it wants to make modules more flexible it would be nice to have the two files be "merged" into one module. This is because sometimes the file layout is different than the logical code layout for whatever reason.
There are also other advantages to this such as creating a /dev/null style module that files can join if they do not want to be a part of the documentation. This way you don't have to specify every file on the command line but are still able to hide files.
I like this idea, but it has to be done carefully, since there is a assumption that modules map to files. A multi-file module would usually be one file that exposes the interface, and some files for the implementation. Those are the files we don't want to include. It does seem better to let the files themselves specify whether they're in or out, and then just a simple wildcard in the config.
I like this idea, but it has to be done carefully, since there is a assumption that modules map to files.
Completely agreed.
A multi-file module would usually be one file that exposes the interface, and some files for the implementation.
Possibly although there are other scenarios (I have seen some weird file splitting in C). And it might be useful to document the implementation for developers. Something like an "internal" tag would be nice.
Those are the files we don't want to include.
The null module idea would be useful here.
It does seem better to let the files themselves specify whether they're in or out, and then just a simple wildcard in the config.
I like control :)
FYI: I once added support for @internal to the original luadoc. Its purpose was indeed to mark certain functions to be not part of the public API even though their scope was public. By default the documentation for such functions would not show up in the output unless you explicitly requested it from the command line.
I would certainly like to see @internal support being added to LDoc.
That should not be difficult. Currently there's an option to mark up non-public functions and only generate docs for them on special request, but I like this tag.
This strikes me as a good feature. One of LDoc's goals is to get out of the way of the developer, and not impose any structure on their code. What we currently have is the submodule tag, which is intended for modules which optionally extend a namespace. But that isn't exactly what we have here. In C the names of the source files have no logical relationship with the modules (unlike Lua) so I see no problem with a rule which looks to see if a module has already been opened, and just adds to it. It should work pretty much as you have written. Should have that in a few days, since 1.3 is in ... continuous release at the moment!
Sorry man, it was Christmas and I had too much to drink ;) 1.3 release continues to roll, mostly fixing problems, but I do want to try module merging in the next week, if that's ok with your time frame.
Hi Kevin, 1.3.3 tag has experimental merge functionality, but you have to activate it explicitly. See tests/merge directory. Should work fine with C files as well (LDoc should not care) but please try this out and see.
That does look nice, but I note a CSS fail here on Firefox; method summaries are forced onto the right, and overflow the table. Not much of a CSS expert, so I can't immediately see a fix. Wonder if we should enforce a width for the first table and make the function proto overflow?
No provision for sorting methods (or generally members of a section) but it would not be difficult to add.
This must be documented even though it's experimental. Works like a charm!
