> > For example, you suggested setting MANROFFOPT=-rU0, which looks like > > an option to be passed to a "roff" program by "man", but the program > > might not recognise that option, and then you might not get a manpage > > at all. > > Your objection is premised on incomplete information.
Indeed, as I am not familiar with groff options. It was a theoretical problem. As we are stripping out the sequences instead, it is a moot point. On Sun, Jan 11, 2026 at 02:32:39PM -0600, G. Branden Robinson wrote: > > Fortunately, it seems that not too many manpages are generated with > > these sequences, except groff's own manpages. I suggest you do not > > start outputting these sequences by default for any manpage > > cross-references, otherwise there are too many. > > On the contrary, the plan is for wider adoption. Alejandro Colomon of > the Linux man-pages project has been waiting on me for a while to finish > submitting a series of patches that would convert the 3,100 or so man > pages that project distributes to use of groff man(7)'s `MR` macro, > introduced in groff 1.23.0, which enables production of the hyperlinks. [...] > > The occasional web URL is probably ok. > > > > This change to groff output also breaks any other program that would > > use the output from "man". > > It breaks programs that don't correctly support ECMA-48. Unsupported or > malformed escape sequences must be discarded, not emitted literally. > > grotty's OSC 8 feature was planned and implemented with substantial > consideration, field trials, and user consultation. That's a very abstract statement, which requires trust on the part of the reader that it refers to something substantial. > The root of the > problem observed is info(1)'s poor conformance with ECMA-48. Regardless of info's comformance with standards, I advise you to pay due concern to the effects on compatibility by changes to groff's output. The "info" program worked well as a manpage viewer, and with your changes it won't, until users upgrade to a newer "info" program (which hasn't been released yet, and which in any case would take years). Such loss should be weighed against whatever you hope to gain by the change. It is a very weak argument for breaking compatibility with other programs that the other programs were not standards-conformant. > The GNU Project regards standards published by other organizations as > suggestions, not orders. We consider those standards, but we do not > “obey” them. In developing a GNU program, you should implement an > outside standard’s specifications when that makes the GNU system better > overall in an objective sense. When it doesn’t, you shouldn’t. https://www.gnu.org/prep/standards/html_node/Non_002dGNU-Standards.html As I said, it will likely not only be the "info" program that is affected. In any case: you would not expect "info" to be ECMA-48 compliant, as that is a standard for text terminals, and "info" is not a text terminal. Therefore we would not expect it to be able to interpret arbitrary terminal control sequences in input files. Nobody at any point in the history of the development of the program has ever gone through the ECMA-48 standard with an aim to comply with it. As you probably understand, "info" runs "man" to get textual output, which it then displays. The output of "man" is thought of as a text file, rather than raw bytes to be sent to the terminal. (Cursor movement sequences, for example, would be inappropriate to pass through to the terminal, as these would interfere with info's display routines.) This textual outupt can contain some control codes for marking text with styles like bold or underline ("SGR" codes), which Info recognizes. I expect it is likely that other programs reading the output of "man" would be likewise limited to supporting those sequences which are likely to occur. (It's possible that versions of "info" older than about 2022 would be unaffected, as we had to make a change to set MAN_KEEP_FORMATTING=1 (on 2022-03-05) to get bold and underlining in manpages, but I haven't tested older versions.) > If these problems have gone unraised by Texinfo users for a long time, > my surmise is that users of info(1), and of GNU Emacs's WoMan man > browser, have such low expectations of their rendering that they > disregard any formatting errors they see. Users of "info" do not use the program to view content with arbitrary terminal control sequences. The program is limited to viewing Info files (the contents of which are predictable and do not contain such sequences), and manpages, which also have been limited to containing SGR sequences. So the situation you describe of "info" users viewing distorted output and being happy with it does not have any reality. I suggest you consider a slower roll-out of this feature to minimise compatability issues. Use of SGR sequences in grotty output (which info now benefits from) was a similar situation historically. Previously, groff output "overstrike" sequences for bold and underline, but switched to SGR sequences at some point. As I remember, this was disabled by distributions (Debian) for many years due to the potential for backwards incompatibility. Eventually though, other programs caught up and it was not so harmful to make the switch and get the benefits of the new functionality.
