Follow-up Comment #13, bug #58946 (project groff): Arrrrgh!!! Why can't savannah offer a sane UI, like OSDN? Please ignore [comment #12 prematurely submitted comment #12], (which I seem to be unable to either edit, or delete)!
Here's what I wanted it to say: [comment #11 comment #11:] > > I'm wondering if there may be some justification for incorporation of > > simplified versions of [XH and XN], and maybe also a minimal default > > implementation of "XH-UPDATE-TOC", within s.tmac? > > > > What do you think? > > I think "yes"! Please go for it. ... I've attached two proposed patches; [file #52067 patch #52067] adds minimal implementations of XH and XN, (together with default implementations of ancillary hooks XH-INIT, XN-INIT, XH-UPDATE-TOC, XH-REPLACEMENT, and XN-REPLACEMENT), to s.tmac, while [file #52069 patch #52069] removes the default XH-INIT, XN-INIT, and XH-UPDATE-TOC implementations from spdf.tmac, (adopting those from s.tmac), and reimplements XH, and XN *indirectly*, in spdf.tmac, using XH-REPLACEMENT and XN-REPLACEMENT respectively, rather than redefining XH and XN directly. In s.tmac, I've preserved the same calling syntax for XH, XN, and XH-UPDATE-TOC, as I originally specified in spdf.tmac, (and as outlined in comment #10), *except* that the -N, -S, and -X options are unsupported, for XH and XN; I have retained <outline-level> as a mandatory argument to XH-UPDATE-TOC, (even though the default implementation in s.tmac ignores it), since it is an essential component of the interface design. I did agonize, for some time, over the default implementation of XH, (specifically, how it should be protected against use before SH); I eventually decided that, unlike the misuse of XN before NH, no such protection is actually necessary. _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?58946> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/