Why I'm hesitating to switch to D

[Adam D. Ruppe]

Andrei:
> Yah, agreed. I've done some work on that in the past; ideally each
> construct would generate a div/span with its own class and then
> everything would be controlled by CSSs.

Yes, indeed. I'd like to go a little further than it goes now too,
specifically, I'd like for any D identifiers - function names,
etc. - that's outputted by the generator to be a macro too.

For example, in code snippets or in function signatures.


MyStruct myfunction();

Shouldn't just output, it should be like:

$(DDOC_GLOBAL_NAME module.name, MyStruct) $(DDOC_PSYMBOL myFunction)();

(or maybe wrapping the return value in yet another macro. The more
information we have, the better.)

Why? So the global name can be translated right into a link.
Ideally, you should be able to click on *any* D name in the
docs and go right to it.


The compiler can tell the scope too - global if the name is from
another module. _NAME if it's from this module. _LOCAL if it's
a local variable in a function example.


This way, the macro can link straight to anything, with all
the accuracy of the compiler's scoping and overload resolution
rules.


A textual post-processor can't be that accurate, so the links
won't necessarily be accurate.

But, even if the compiler did nothing but identify identifiers
and pass the name to a macro, that'd be an improvement since it
can always link to a search engine,
(Like my own http://dpldocs.info/NAME ) for the final resolution.



This lack of easy cross-referencing in examples and signatures,
especially across modules, is the only problem I have with ddoc
itself right now.