Allow Module Merging about ldoc HOT 9 OPEN

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.

from ldoc.

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 :)

from ldoc.

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.

from 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.

from ldoc.

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!

from ldoc.

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.

from ldoc.

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.

from ldoc.

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.

from ldoc.

This must be documented even though it's experimental. Works like a charm!

from ldoc.