> 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. It only supported
sequences that were likely to occur in practice: not arbritary
sequences from standards for text terminals.
You can argue about what a "pager" should or shouldn't do; the fact
is this is an incompatible change in groff (or grotty) output.
Regardless of whether philosophically speaking such sequences should
have been supported from the start, the fact is they weren't, and
breakage is breakage.
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.
> When you say "info" deals with the output of "groff", you're being less
> precise than the discussion requires. "info" handles the output of
> "grotty". What is grotty?
>
> grotty(1):
> grotty - groff output driver for typewriter‐like (terminal) devices
>
> 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.
> If "info" has particular needs for the output of a groff pipeline, I
> reckon the best approach is to specify what those needs are, and we can
> see if someone's willing to write an output driver for it. As Texinfo
> is a fellow GNU Project, I'd personally take seriously the expression of
> such demand.
>
> There's a more challenging alternative: "info" could interpret GNU
> troff's (or, for that matter, AT&T troff's) output directly, which would
> be the equivalent of implementing a *roff postprocessor internally. I
> don't think that would be a great idea, as it would run counter to the
> principle of modular design.
Sorry, I am not familiar with all the distinctions between GNU troff,
groff and grotty or what this "output" refers to. "info" processes
the output of running "man" and doesn't concern itself with troff or
groff internals as far as is possible.
> 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.
> > It is a very weak argument for breaking compatibility with other
> > programs that the other programs were not standards-conformant.
>
> The _standard_ way to find out what capabilities a terminal has is to
> employ the terminfo library.[4] Unfortunately, no version of nroff has
> ever done that. At one point I was convinced that this was a gravely
> lacking feature in groff, but I've become much less alarmed for the
> simple reason that the overwhelming majority of consumers of nroff
> output do so via the intermediation of a pager. (And for those who
> produce nroff _without_ paging it, its output is sufficiently
> well-behaved, ECMA-48 conformant, and above all unambitious enough that
> it seldom draws complaint.)
(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.)
> > 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?
> > 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. As I said before,
it seems to be mainly the groff manpages that are affected. That could
explain the lack of reports. It's also possible that people don't know
how to report bugs or don't feel it is worth their time.
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.
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.
> 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). 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.
