Cross referencing in Ddoc

Sönke Ludwig sludwig at outerproduct.org
Mon Dec 30 16:05:34 PST 2013


Am 31.12.2013 00:37, schrieb Walter Bright:
> On 12/30/2013 3:13 PM, Sönke Ludwig wrote:
>> Am 30.12.2013 23:13, schrieb Walter Bright:
>>> On 12/30/2013 1:25 PM, Sönke Ludwig wrote:
>>>> Identifiers in documentation comments that are function parameters or
>>>> are names that are in scope at the associated declaration are
>>>> emphasized
>>>> in the output.
>>>>
>>>> So the same problem is already reality - you already have to go through
>>>> the documentation to see if there are any mis-highlighted words.
>>>
>>> 1. having a bad idea is not justification for doing it again :-)
>>
>> Of course not, but my point was that the mistake has already been made,
>> so we may as well make the best out of it... not really doing it again
>> in that sense.
>>
>> But if the decision is that in fact this was a mistake, it should get
>> removed and replaced by a proper solution sooner rather than later (it's
>> not that bad to lose some highlighting and Phobos uses $(D ...) anyway,
>> so just removing it wouldn't hurt much).
> 
> Ddoc is very heavily used. I don't believe we can make such silent,
> breaking changes.
> 

It's just word highlighting! Breaking changes in the language are one
thing, but this kind of fix is a whole different category. Keeping it
will only make the problem worse over time. If there is a reasonable
deprecation path, that would be better, of course, but the current
situation is the worst of all possibilities.

> 
>> And in that regard I'd like to
>> point to "D's goals for embedded documentation"
>> <http://dlang.org/ddoc.htm>. I very much agree with them, but the
>> current reality looks like the opposite - lots of macro-pseudo-HTML
>> markup, very difficult to read unprocessed in many places. So something
>> like using "#" or "()" to mark symbols + automatic cross referencing for
>> marked symbols would be a *really* nice to have.
> 
> I don't see any particular advantage to using (name) rather than $(REF
> name), and some serious disadvantages with false positives like
> func(param). Oops! A markup language should really strive to minimize
> special syntax. (I'm often tripped up by false positives in the wacky
> markup languages in Skype, Github, Reddit, etc., each of which feels
> compelled to reinvent markup.)

It's not "(name)", but "name()" or "name(param)", which is recognized as
a function call. "#name" also forces recognition as an identifier, as
well as "::name" in C++'s case.

I agree that going overboard with special syntax is a bad idea, but
symbols in a code documentation language is such a fundamental thing
that it should surely be among the first things, if not *the* first
thing, that deserves a concise syntax.

Also, the official first four goals of DDOC are:

> 1. It looks good as embedded documentation, not just after it is
>    extracted and processed.
> 2. It's easy and natural to write, i.e. minimal reliance on <tags> and
>    other clumsy forms one would never see in a finished document.
> 3. It does not repeat information that the compiler already knows from
>    parsing the code.
> 4. It doesn't rely on embedded HTML, as such will impede extraction
>    and formatting for other purposes.

Using $(XREF), $(TABLE $(TR $(TD ...))), $(LINK a b) $(D ...) and so on
is nothing but markup. If we go that route, we could as well remove all
syntax, except for the macros:

$(SUMMARY ...)
$(SECTION See_Also
   ...
)
$(PARAMS
  $(PARAM x ...)
  $(PARAM y ...)
)
$(SECTION Example
  $(CODEBLOCK
    ...
  )
)

But you added the syntax for a reason back then (readability ...and
writability). And the same goes for the auto-detection of identifiers. I
think the only problem is that the default would have been better off
the other way around.



More information about the Digitalmars-d mailing list