On Thu, Jan 15, 2026 at 11:36:05AM -0600, G. Branden Robinson wrote: > > It only supported sequences that were likely to occur in practice: not > > arbritary sequences from standards for text terminals. > > How was the measurement of "likely to occur in practice" undertaken? >
By the experience of developers and user reports. > > the fact is this is an incompatible change in groff (or grotty) > > output. > > That's why it appeared in groff 1.23.0 "NEWS" file, where feature > changes are traditionally announced. > > https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/NEWS?h=1.23.0#n548 > > For man(7) documents, in that release, production of OSC 8 escape > sequences was available but not enabled by default, for the precise > reason you're giving me grief now. > > https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/tmac/man.local?h=1.23.0 People who use "man" output wouldn't generally look at the NEWS files from groff. They would just notice one day that the program was broken. > I see the following (complex) item in Texinfo's own "NEWS" file: > > [...] > > Explain to me why it would be unjust for me make the same complaints to > you about those changes to "makeinfo" that you're making to me. It would not be unjust for you to complain if such changes broke your use cases. I did not say that programs should never break compatibility, ever. I said that changes should be done with care and judged on their merits. We have made incompatible changes before, but try to minimise the breakage by giving time for updates. For example, in the 7.2 release we changed the format of auxiliary files output by texinfo.tex processed with TeX. This broke compatibility with older versions of texi2dvi, which wouldn't recognise files in the new format: 7.2 (23 December 2024) [...] * texinfo.tex . use @ as the escape character in all index files. this requires new enough texi2dvi (Texinfo 6.7, 2019) for index files to be properly processed. We haven't had any complaints so far about the incompatibility, which was helped by giving time for the incompatible program to be upgraded. As for the changes to groff, the pathway I suggest is: * Publicise the changes to projects that use man output * After some time has passed, use the new ouptut in a limited way (e.g. web URLs which don't occur so often in manpages). This would give more opportunity for the changes to be detected and for people to adapt. * After further time has passed, use the new output more freely once support is commonplace. > > As data intended for a text terminal diverges from what would be > > printed on a typewriter, support in a pager would be expected to be > > less. As you point out, nobody would expect to be able to play > > nethack through the "less" pager. > > > > An embedded "Operating System Command" in a text stream could do just > > about anything and so you wouldn't expect a pager to have much support > > of such a control sequence. > > I agree. That's why common ("standard"?) practice is to discard them. Section 5.6 of ECMA-48 (1991) also lists several more types of "control string": The opening delimiters defined in this Standard are a) APPLICATION PROGRAM COMMAND (APC) b) DEVICE CONTROL STRING (DCS) c) OPERATING SYSTEM COMMAND (OSC) d) PRIVACY MESSAGE (PM) e) START OF STRING (SOS) Do you think we should be trying to discard any or all of these as well? Is this what "less" does? It is potentially creating a lot of work for us to implement checks for terminal control sequences as defined by standards, when it's possible that they aren't used in practice. > > Sorry, I am not familiar with all the distinctions between GNU troff, > > groff and grotty or what this "output" refers to. > > You're familiar with Unix pipelines and, I'll wager, with the gross > architecture of a compiler. > > 1. lexical analysis and parsing > 2. abstract syntax tree generation > 3. translation to target-specific assembly language > > "groff" is a front-end orchestrator, like "gcc" in GNU CC. > > GNU troff implements parts 1 and 2, analogously to "cc1" in GNU CC. > > "grotty" is a back-end, like GCC's sundry code generators. Other > back-ends ("postprocessors") are names "grops", "gropdf", "grodvi", and > "grohtml", from which you can likely deduce their targets. Thanks for explaining. > > > > So the situation you describe of "info" users viewing distorted > > > > output and being happy with it does not have any reality. > > > > > > I just observed it myself, hence my bug report. > > > > You observed a happy "info" user looking at mangled output? > > I misunderstood you. I observed unpleasant output and reported an > issue; you implemented a fix, and are now, it seems, explaining to me > why you shouldn't have had to do so.(?) You misunderstand. It makes sense for us to support these sequences, now they've reported to occur in practice. We can only support such changes in output if we know about them. Reporting them, as you did, is a good way to encourage support, as well as announcing it in your project's NEWS file. I'm concerned that users may use info to look at a manpage, see broken output, and then conclude "info is a shit program". They then would be turned off Texinfo. GNU programs should ideally run well together as this supports the existence of a operating system composed of free software. > > The 2½ years since release should be viewed relative to the total > > length of time that troff or groff has existed, not as an absolute > > length of time. > > I have never before heard of this principle that, even an assuming we > had a standardized unit for "software changiness" (c) to use on the > vertical axis of a plot, that a software project's rate of change C in > the time domain should be logarithmic. > > C = (dc/dt)(a ln t) > > [where `a` is some constant that is not important] > > Where did you encounter this notion? It doesn't really matter where I got the idea. Maybe from Donald Knuth's review schedule for TeX.(*) It's what I think about when I get a message on a website that says "your browser is out of date" when my web browser is only 1 and a half years old - a small percentage of the time that HTML has existed. (*) https://cs.stanford.edu/~knuth/abcde.html > Let me know if I can be of assistance in improving "info" as a man > pager. The advantage of "info" over "less" as a man pager is that info supports hyperlinks between man pages. It does this by detecting references that look like man page references. This doesn't work if a reference is split across lines. I found the following in "pipe(2)": SEE ALSO mkfifo(1), dup(2), fcntl(2), open(2), pipe(2), poll(2), select(2), socket‐ pair(2), splice(2), stat(2), tee(2), vmsplice(2), mkfifo(3), epoll(7), fifo(7) Info doesn't recognise the reference to "socket-pair(2)". One idea is not to try not to split such references across lines.
