[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #45034] mdoc(7): add support for the mdocmx(7) reference extension

From: anonymous
Subject: [bug #45034] mdoc(7): add support for the mdocmx(7) reference extension
Date: Sat, 20 Jun 2015 11:24:06 +0000
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:38.0) Gecko/20100101 Firefox/38.0

Follow-up Comment #9, bug #45034 (project groff):

For your interest: today i have seen a case were mdocmx fails.

FreeBSD commit r284611 (Xin LI):

-.Ss Xr devd 8 Ss Events
+.Ss Xr devd 8 Events
 Hotkey events received by
 .Xr devd 8
 provide the following information:

We resolve this as

  .Mx -anchor-spass Ss "Xr devd 8 Events" 4

which (in debug mode) ends up as

  @address@hidden(8) Events[35]

(instead of "devd(8)[35] address@hidden@[11]").
[35] is the (correct) external manual reference devd(8)!

In fact i don't understand why we are able to resolve this at all, i'll
inspect that once S-roff is usable.
My current plan would be to provide debug logs for the preprocessor and i
don't know yet what i can do in mdocmx(7) in order to warn the user.
Can this ever work correctly in non-multipass troff(1) and without rewriting
mdoc(7) as imagined?  I don't know yet.
Like i've said, i'm wondering why we are able to provide correct anchor and
links as such.
For now i think it is absolutely sufficient to state -- for mdocmx -- that
people should use a headline like "Device daemon events" as the headline,
especially since the next output line contains the same reference again.

Final note, since some manuals, including GNU roff ones, sometimes use .Xr
without a reference: if the manual would have been changed to

 .Ss Xr devd Events

we would have got


(or "devd(Events)" in mandoc(1)), so that i truly see the use case as above as
an error.


Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]