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

Follow-up Comment #17, bug #45034 (project groff): See bug #63042 for an attempted resurrection of this issue. ___ Reply to this item at: ___ Message se

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

Update of bug #45034 (project groff): Summary: [PATCH] mdoc(7): add support for the mdocmx(7) reference extension => mdoc(7): add support for the mdocmx(7) reference extension ___ Reply to this item at:

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

Follow-up Comment #14, bug #45034 (project groff): Hello again, yes, this is Steffen, and it is still not the second iteration. But i have found a bug in the "free" links and references implementation, ".Mx -sx" and ".Mx -ix". It is almost a one-line fix. The commit message apologizes to Ingo Sc

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

Follow-up Comment #13, bug #45034 (project groff): Hello again (yes it's Steffen), this is not about the second iteration but two real bugs have been found in the meanwhile and since i really enjoy mdocmx(7) i'm eager for posting the fixes. Sorry for the noise :) Two bugs in the preprocessor:

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

Follow-up Comment #12, bug #45034 (project groff): And sorry for the for weird resulting format, this tracker is too fancy for me. ___ Reply to this item at:

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

Follow-up Comment #11, bug #45034 (project groff): Ingo's #9: > Bad idea. Don't use macros in header lines. Hm, tja, na ja... >> 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

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

Follow-up Comment #10, bug #45034 (project groff): Regarding comment #9: > .Ss Xr devd 8 Events Bad idea. Don't use macros in header lines. > 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,

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

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): share/man/man4/acpi_ibm.4: -.Ss Xr devd 8 Ss Events +.Ss Xr devd 8 Events Hotkey events received by .Xr devd 8 provide the following information:

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

Follow-up Comment #8, bug #45034 (project groff): So ok, i've added a "mx-toc-disable" string as well as enabling PDF annotations. I've not yet added macro-hooks to back .Xr with functionality for formats other than TTY. It would _maybe_ make sense to add a complete set of hooks so that indices

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

Follow-up Comment #7, bug #45034 (project groff): ah - and i wonder what could be done to support those .Xr external references in an output format like, especially, PDF: i think i'll also add a ".if d MACRO" to optionally build an URL? I see your program does support .Xr, being able to specify a

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

Follow-up Comment #6, bug #45034 (project groff): Hello, :The nail.pdf looks quite similar to this:- : :http://chuzzlewit.co.uk:8080/cgi-bin/WebManPDF.pl/man:/nail : :Which is a program which converts man pages, of all types - not :just mdoc, to pdf format. I do prefer having the "Contents" :sect

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

Follow-up Comment #5, bug #45034 (project groff): The nail.pdf looks quite similar to this:- http://chuzzlewit.co.uk:8080/cgi-bin/WebManPDF.pl/man:/nail Which is a program which converts man pages, of all types - not just mdoc, to pdf format. I do prefer having the "Contents" section in the link

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

Follow-up Comment #4, bug #45034 (project groff): Ingo, sorry for being so loud. I also forget to mention in this bug report that you were the initial designer of the interface -- you are of course mentioned in the manual page! I now also think it is best to give some easy-accessible examples,

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

Follow-up Comment #3, bug #45034 (project groff): "Significant simplification"? "Completely unstable"? "Purely experimental"? _NONE_ of these are true! Where did you get ANY evidence that back your words? I have extended the following manuals with mdocmx(7): - mdocmx.7, mdocmx.1. Small and simp

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

Follow-up Comment #2, bug #45034 (project groff): It's nice to have this code in the bugtracker, but please don't include it into groff yet. I very strongly urge people to not use these features for real-world manuals yet for lack of portability. Before this can become usable in practice, it wil

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

Follow-up Comment #1, bug #45034 (project groff): Oops, groff-1_22_3.diff includes addition of a .hash troff(1) request! This is of course no(t) (longer) needed! Find attached the diff without .hash (otherwise identical). Sorry!! (file #33939) ___

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

URL: Summary: mdoc(7): add support for the mdocmx(7) reference extension Project: GNU troff Submitted by: None Submitted on: Wed 06 May 2015 11:53:12 AM UTC Severity: 3 - Normal