At 2026-01-13T20:02:01+0000, Gavin Smith wrote: > > I agree. That's because "info" is, among other things, a pager. > > Yes, "info" is a pager of sorts. It is one that supported a limited > subset of data that would be sent to a terminal.
Okay. What _kind_ of terminal? What's in-band for one can be a control or escape sequence on another. > 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? > You can argue about what a "pager" should or shouldn't do; I already stated a definition: a program that intercepts output intended for a terminal so as to paginate it.[0] > 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 > Regardless of whether philosophically speaking such sequences should > have been supported from the start, the fact is they weren't, and > breakage is breakage. Feature changes are feature changes. I see the following (complex) item in Texinfo's own "NEWS" file: ---snip--- * Intentional incompatibilities with the previous implementation of makeinfo, through version 4.13: . The old implementation accepted a lone block of text inside @itemize, @enumerate, etc., without any @item. This is semantically inconsistent, leading to problems with some backends, and thus now produces a warning. . The old implementation accepted ``irregular'' sectioning trees. Now, when @node pointers are implicitly determined, the consistency of @menu and the sectioning tree is checked. (If node pointers are explicitly specified in the document, the tree can still be irregular.) . The old implementation always added blank lines between function definitions if they weren't already there. Now blank lines are not added. (Both old and new implementations preserve blank lines that are present.) . The old implementation processed macros in place, formatting the replacement text with the output. Now the replacement text is textually substituted as Texinfo source. A consequence of the old behavior is that ends of lines from expansion of an @macro definition did not end an @-command line-delimited argument (@chapter, @center, etc.). Now they do. (A detailed example is in the manual, node Macro Details.) ---end snip--- 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. > 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. > > If you want groff to format a document for something that isn't a > > terminal device, don't tell it to postprocess the document for > > output to a terminal! > > In practice the piped output from grotty can be thought of as a text > file with some exotic features. "Exotic" is a nice choice of term. What is the name of the catalog in which we can look up the fantastic beasts one might encounter? > 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. > "info" processes the output of running "man" and doesn't concern > itself with troff or groff internals as far as is possible. That's a sound decision, and I don't ask you to revisit that choice, only to be more cognizant of what assumptions underlie your distinction of "plain text" from "output to a terminal". > > I have little confidence that subscribers to bug-texinfo@gnu > > actually read all of that, so here are the bottom lines. > > > > 1. If your program interposes itself between the output of a Unix > > command and the terminal device at which it was directed, > > whether you're an AWK script or a pager, your program has to > > plausibly simulate a terminal. If you don't, your users will be > > unhappy. There's no essential difference between > > f^Hfo^Hoo^Hob^H_a^H_r and SGR or OSC escape sequences here. > > Some techniques are simply older than others, and all vary in > > breadth of deployment. > > Yes, no essential difference, except in the age and breadth of support > for such sequences. 'twas ever thus. 2BSD introduced termcap in 1980. https://minnie.tuhs.org/cgi-bin/utree.pl?file=2BSD/src/termlib/termcap > (Pedantically, it's possible that the timing of bytes sent to a > terminal device also makes a difference, and this information is not > taken into account when a pager is used.) Yes! This is why it's a good idea for terminal emulator authors to define their own terminal types and work with terminal capability database maintainers to accurately describe their implementations, instead of glibly claiming "compatibility" with some existing terminal. In practice, terminal emulator developers are _terrible_ at reproducing the behavior of terminal devices or even other terminal emulator programs. https://invisible-island.net/ncurses/ncurses.faq.html#no_padding https://invisible-island.net/ncurses/man/ncurses.3x.html#h3-NCURSES_NO_PADDING https://invisible-island.net/ncurses/terminfo.src-entries.html#tic-vte-2007 https://invisible-island.net/ncurses/terminfo.src.html#tic-kitty https://invisible-island.net/ncurses/terminfo.src-entries.html#tic-alacritty (from these links, scroll up to see commentary) > > > 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.(?) > > > Eventually though, other programs caught up and it was not so > > > harmful to make the switch and get the benefits of the new > > > functionality. > > > > Right. And the same thing is happening here. That groff 1.23.0 has > > been out for 2½ years and I'm apparently the first person to bring > > the issue to this lists' attention tells me that the population of > > people using a groff of anything like recent vintage and also employ > > "info" to view man pages is pretty small. What conclusion would you > > reach? > > In my experience, I view manpages with "info" all the time and have > not encountered the breakage until you reported it. I deliberately give groff man's `U` register a true Boolean value in my installation _so that_ I will find issues like this one. Would you rather not have heard about it? > As I said before, it seems to be mainly the groff manpages that are > affected. All of the macros that can produce hyperlinks are groff extensions to the man(7) package. (groff is not the first troff implementation to have implemented extensions, but folk wisdom among man page writers seems to be that whatever interface their local installation supports is what all Unixes supported going back forever. This was true for less than a year after the release of Seventh Edition Unix in 1979.[2][3]) Anyway, the "Hyperlink macros" section of groff_man(8) presents them. Most (MT, ME, UR, and UE) are about 17 years old. `MR` is either 5 years old or 2½ years old, depending whether you care about Plan 9 from User Space. Linux man-pages 6.16 has 117 occurrences of the `UR`/`UE` macro pair to delimit URLs. > That could explain the lack of reports. More likely, I think, is that it's because the feature defaults off in groff 1.23; people don't read documentation; and they have already decided that man pages don't support hyperlinks, so they reject a priori any evidence that they do. > It's also possible that people don't know how to report bugs or don't > feel it is worth their time. Always a hazard. :( > It's quite common for users to run software that is years out of date > or for distributions to prefer older versions. And support is only > being requested now in "info", regardless of the length of time that > has passed. It's very likely that other users of grotty output don't > know about the changes either yet. As above, defaulting the feature "off" was my attempt to achieve the gentle rollout you seem to be hectoring me to undertake. Or I'm misunderstanding you, and you are coaching me to leave the feature disabled by default forever, and/or to withdraw it. > 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? > > If you don't intend ever to support hyperlink-style navigation in > > "info" for non-Info documents, then there may never be a reason to > > revisit that decision. > > [...] > > > As "info" is already a hypertext system, it'd be nice if it could > > use hyperlink information that man pages rendered by groff 1.23.0 > > can offer. That would necessitate interpreting OSC 8 sequences > > instead of discarding them. > > > > I'm curious to learn of your interest in such a feature. > > I haven't said that I'm not interested in the feature. I can see Info > making use of it in the future (but not in the next release). No, I wouldn't ask that when you're in what I'd term the "release candidate" phase of the development cycle. > For example, Info files can contain web hyperlinks. Additionally, in > the upcoming release, there is a new "hooks" feature that can report > to the user messages like this if an Info manual is not installed: > > An Info manual called 'elisp' was not found on your system. > > You could try visiting the following URL in a web browser to > download the Info manual, or to read the 'elisp' manual in other > formats: > > https://www.gnu.org/software/emacs/manual/elisp.html > > Linkizing that link with OSC 8 could certainly be useful in helping > users to access the documentation. Sounds promising. I'd urge you to play with the "^O" featured of recent "less". It'd be nice if there were a consistency of approach (with respect to feature mechanics, not necessarily key bindings) among GNU tools. Let me know if I can be of assistance in improving "info" as a man pager. Regards, Branden P.S. for Unix/hardware antiquarians: Check out the function of pin 25 on the Teletype Model 37's EIA Interface, p. 10. https://www.navy-radio.com/manuals/tty/m37/574-304-100-iss2-7212.pdf [1] "Pagination" can have a couple of meanings; the traditional Unix pr(1) program paginates for paper that is cut into sheets (contrast the continuous paper rolls used by Teletype machines). However in the present discussion we're both using it to refer to a process of buffering output for a video terminal (or emulator thereof) to facilitate user-directed scrolling and, often, other operations. The GNU "less" pager's feature list is fairly lengthy. [2] groff_man(7): History M. Douglas McIlroy ⟨[email protected]⟩ designed, implemented, and documented the AT&T man macros for Unix Version 7 (1979) and employed them to edit Volume 1 of its Programmer’s Manual, a compilation of all man pages supplied by the system. The package supported the macros listed in this page not described as extensions, except P and the deprecated AT and UC. It documented no registers and defined only R and S strings. UC appeared in 3BSD (1980). Unix System III (1980) introduced P and exposed the registers IN and LL, which had been internal to Seventh Edition Unix man. PWB/Unix 2.0 (1980) added the Tm string. 4BSD (1980) added lq and rq strings. SunOS 2.0 (1985) recognized C, D, P, and X registers. 4.3BSD (1986) added AT and P. Ninth Edition Unix (1986) introduced EX and EE. SunOS 4.0 (1988) added SB. Unix System V (1988) incorporated BSD’s lq and rq strings. Except for EX/EE, James Clark implemented the foregoing features in early versions of groff. Later, groff 1.20 (2009) resurrected EX/EE and originated SY/YS, TQ, MT/ME, and UR/UE. Plan 9 from User Space’s troff introduced MR in 2020. [3] Some of the blame for this confusion on the part of man page authors could be attributed to the evident reluctance of past authors of man pages for man(7) itself; most seem to treat their troff's macro package sui generis, as if no others exist.
signature.asc
Description: PGP signature
