Follow-up Comment #4, bug #68299 (group groff): On Thursday, 30 April 2026 21:53:46 BST you wrote: > Follow-up Comment #3, bug #68299 (group groff): > > At 2026-04-30T16:19:52-0400, Deri James wrote: >> Follow-up Comment #2, bug #68299 (group groff): >> >> On Thursday, 30 April 2026 19:51:36 BST you wrote: >>> What distinguishes this ticket from bug #67665? Does this one >>> supersede the earlier one? >> >> That bug concerned pdfms.tmac which operated as an addon (in the same >> way as spdf.tmac was an addon to pdfmark.tmac, which required the user >> to use the newer NH/XN combination rather than the original NH to >> create bookmarks). > > Ahhhhaaaaa. </TomBaker>
Who? >> Given that most historical ms documents would use NH (with XS/XE if a >> TOC was required), I wanted to make s.tmac support them without adding >> non roffish flag letters to macro calls. The use of ".pdfhref M" to >> "mark" a position in the document is unfortunate, I would prefer a >> native ms macro such as:- >> >> .XM name [text] >> >> instead. > > I share your preference. I've added it. Now the only feature missing from ms is "external links" (you have to use ".pdfhref W -D URI ...", so not very ms). How about "borrowing" UR/UE (MT/ME) from man? >> This could also obviate the need for dual working tricks based on >> testing PDFFEAT. I didn't feel confident whether extending the s.tmac >> repertoire of commands was really my choice. > > groff_ms(7) (and of course ms.ms) documents many extensions. Some are > Berkeley's, some are Unix V10's, and some are ours. > > Further, groff ms doesn't work in compatibility mode, so a hard-bitten > legacy document written in old-school ".dsabcd" style won't work anyway. > I've had some exchanges on this subject with Clem Cole, who is using > groff to render some early Unix System V-era man(7) and ms(7) documents > with groff, to incomplete success. Is this something I could help with, an example document(s) would help. > Reinforcing existing good idioms is desirable. > > Relieving the document author of having to repeat themselves is too. > > I largely liked Keith's `XN` and `XH` extensions, which reduced the > amount of labor required by the document author to get section headings > into the table of contents. > > (Why only "largely"? I don't completely understand the motivation for > `XN-REPLACEMENT`, when one can replace `XN` itself. And I regret that > there's no ability to suppress the leader dots, as one might desire for > bridgeheads. Keith also parameterized `TC-LEADER` as a string, but it's > reset only at each TOC in toto, and so is not configurable for the > bridgehead application.) This bit of code confused me too. .de name1 de [...] .de name2 [...] .. Hurts my brain!! There are now 3 places that may want different SNs. The text, the bookmark and the TOC - I left it alone!!! >> The pdfms bug was the "breeding ground" for the code in this bug, and >> allowed you to straighten out the numerous bugs in .asciify upon >> which this code relies. So, it does supercede the original bug. > > Okay. Is there any reason not to resolve that one? No, objection to it being closed. >>> Revising Summary; see >>> [https://lists.gnu.org/archive/html/groff/2026-04/msg00061.html >>> mailing list cogitation]. >> >> I'm happy. Although I must admit to being a bit flummoxed, but if you >> are happy to zoom in and correct my mistaken tags, I shan't worry. > > Doesn't bother me to tidy them up. I can easily keep pace with the > influx of groff Savannah tickets, as evidenced by the fact that I've > submitted 649 of the 1,801 filed to date. Thank you Branden, the amount of work you do is impressive. _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?68299> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
signature.asc
Description: PGP signature
