Hi Ingo, At 2026-08-16T18:56:03+0200, Ingo Schwarze wrote: > G. Branden Robinson wrote on Sun, Aug 09, 2026 at 03:35:57AM -0500: > > > I look forward to seeing the new requests I've added since groff > > 1.22.4 show up. ;-) > > > > stringup > > stringdown > > i just implemented these two, see the commit appended below.
Cool! > With groff-1.24, i see one detail of behaviour that feels at least > somewhat ugly to me, arguably even buggy. Yes, that's a bug. I fixed a similar one for groff 1.25... https://savannah.gnu.org/bugs/?68203 ...but as that one affects only the new debugging request `phw`, and I think you said earlier that you had no plans to implement any of groff's new "p-series extensions", that one that won't be relevant to mandoc(1). > The .stringup request is documented to accept exactly one argument. > However, when i append additional bogus arguments, those sneak > through verbatim to the output stream, at the place of the request, > even though the request is not documented to produce output. Yes, that's quite wrong. As the arguments to `string{up,down}` are _identifiers_, they could be unambiguously space-separated (as with `rm` and `rr`). We could plausibly interpret N arguments, where each N is a string identifier. But as this feature is employed little by users, I'll expect not to bother until I end up reïmplementing `string{up,down}` as macros in a "string.tmac" file. https://lists.gnu.org/archive/html/groff/2024-11/msg00044.html ...and that innovation continues to await my development of the courage/ skill/patience to implement a string iteration request. > For example, with groff-1.24, the input > > .ds mynm content > .stringup mynm trailing garbage > \*[mynm] > > produces this output for me: > > trailing garbage CONTENT > > Groff prints no wraning or error message. Confirmed: $ echo '.stringup foo bar baz' | ~/groff-1.22.4/bin/groff -a | grep . || echo NO OUTPUT NO OUTPUT $ echo '.stringup foo bar baz' | ~/groff-1.23.0/bin/groff -a <beginning of page> bar baz $ echo '.stringup foo bar baz' | ~/groff-1.24.0/bin/groff -a <beginning of page> bar baz $ echo '.stringup foo bar baz' | ~/groff-1.24.1/bin/groff -a <beginning of page> bar baz > In mandoc, i chose to instead only print > > CONTENT > > to standard output and the following to standard error output: > > mandoc: stringup_bad.in:7:16: ERROR: skipping excess arguments: \ > stringup ... trailing garbage That sounds reasonable. While GNU troff does not at this time diagnose excess arguments, the idea's been considered and has an open ticket. https://savannah.gnu.org/bugs/?61450 I recall that elsewhere you expressed a hope that GNU troff would not further develop these requests so as to acquire knowledge of Unicode casing properties. I broadly concur. I'd rather not have such a thing inside the formatter if I can easily avoid it. If I implement that string iterator request, any such transformation logic I suspect could be profitably tucked into that future "string.tmac" file--or into a localization macro file. Turkish and German are examples of languages where we'll need flexibility--the former because of the dotted/dotless i/j switcheroo that it _doesn't_ implement on case switches, and the latter because, as has come up on this list before, some users might want ß uppercased as "SS" and others might prefer U+1E9E ẞ. Best to confine such fiddly matters to macro logic outside of the formatter. I don't anticipate lettercase alteration becoming a site of performance degradation. > Log Message: > ----------- > groff-1.23.0 invented new roff(7) requests .stringup and .stringdown > that change the case of the named user-defined string in place. I > haven't seen them used in any manual page yet and - like for all > roff(7) requests - do not recommend using them, but i chose to > implement them anyway because that was almost as trivial as it would > have been to mark them as unsupported. [snip] Yup. And groff_man_style(7) continues to offer equivalent advice. Portability ... In roff systems, elemental functions called requests and escape sequences control formatting operations. A request appears on a control line. An escape sequence starts with a backslash (\) and can appear almost anywhere. However, use of roff requests (apart from the empty request “.”) risks poor rendering when a page is processed by non‐roff formatters that attempt to interpret page sources. (Historically, this was commonly attempted for HTML conversion.) Many of these programs don’t interpret the full roff language (let alone extensions): they may be incapable of handling numeric expressions, control structures, or register, string, and macro definitions, causing a document’s contents to be presented incomprehensibly or omitted entirely. If your document uses formatter requests, or escape sequences not shown below, it accepts responsibility for restoring formatter state to what the man macro package expects. ... Exercise restraint with escape sequences as with requests. Some escape sequences are however required for correct typesetting even in man pages and usually do not cause portability problems. ... Thanks for the report! Regards, Branden
signature.asc
Description: PGP signature
