Re: Why are tty-char.tmac and tty.tmac separate files?

[Dave Kemper]

(Heavily edited your reply to exclude points that needed no reply or
where I agree with you.)

On 7/16/22, G. Branden Robinson <g.branden.robinson@gmail.com> wrote:
> I can distinguish them in a few ways.

Agreed, there are differences, but to clarify my question: are there
situations where a user would want one included but not the other?
Because if the answer to that is no, there's not much point to keeping
them separate.

And if the answer is yes, the documentation could sure do a better job
of explaining what those situations are.  It explains clearly enough
HOW to invoke one or both, but no motivation for taking advantage of
these separate knobs.

> First of all, there is always a macro file named for the output driver
> that gets run via troffrc.
...
> tty.tmac does a few things that _aren't_ character/glyph
> definition-related.

Fair enough.  tty.tmac is part of a cohesive infrastructure, and
contains essential terminal support beyond character transformations.

> Finally, it conditionally loads some macro files particular to the
> output character encoding.  Those in turn deal with the translation of
> input character code points.  (I find these facts to be in some tension,
> and it may be part of what Werner flagged years ago as an undesirable
> coupling between character encodings and output devices.)

Filed at http://savannah.gnu.org/bugs/?60536, if anyone has comments
specific to this issue they want to add to its permanent record.

>> (And in this case, which fallback definition of the arc-second sign is
>> "superior" is a judgment call,
>
> I think that definition in tty-char.tmac should be dropped.  I added
> fallbacks in tty.char for \[fm] and \[sd] (both CSTR #54 glyphs) in May
> 2021.  I seem to remember that Ingo followed suit at least for the
> latter in mdoc.

Sure, dealing with conflicting definitions is the low-hanging fruit of
this discussion, and useful as a first step.

>> tty.tmac defines two glyphs in terms of \[rn], but
>> \[rn] is defined for terminal devices in tty-char.tmac.
>
> What I was trying to do was shut up warnings from the groff_char(7) man
> page.

That works on a man page, which is nearly always viewed through the
"man" interface, which is guaranteed to call nroff for terminal
output.  But it doesn't solve the general case:

$ echo 'Free \[radicalex] now!' | nroff | cat -s
Free ¯ now!

$ echo 'Free \[radicalex] now!' | groff -Tlatin1 | cat -s
troff:<standard input>:1: warning: can't find special character 'rn'
Free  now!

$

> I can imagine a world where you
> use tty.char when you're trying to test a document in some kind of
> device-independent way, and you use tty-char.tmac when you need
> "practical" rendering.
>
> But for that scenario to hold, practically all fallback character
> definitions need to move from tty.tmac to tty-char tmac.

Putting all the like things in the same place does seem like an
improvement.  The qualitative difference between the definitions
currently in different files can be pointed out in code comments, so
that this distinction remains documented.

However, removing all fallback characters from tty.tmac will result,
in cases where tty-char.tmac is not loaded, in some number of special
characters provoking warnings and being omitted from output entirely.
This seems less than useful for the goal of testing terminal output in
a device-independent way.  Or I'm fundamentally misunderstanding your
proposed use case.

> Perhaps the notion was to
> someday deprecate nroff in favor of groff's grand unification of data
> flow.  And man-db(1) man seems to honor that intention.

Not sure what this means.  man-db's "man" calls "nroff" for terminal
output, according to its own man page and to debugging info generated
with "man -d".  (At least, as of man-db 2.9.3, which is admittedly not
the bleeding edge.)

> I personally find groff's nroff command to be useful and a
> keystroke-saver.

Definitely.  But in a world where /path/to/troff and /path/to/nroff
link to the same executable, and this executable looks at how it was
invoked to see how to initialize itself, grotty could then be
responsible for figuring out the terminal's character encoding,
currently done in nroff.sh.  (Theoretically.  In practice, nroff
historically doing this work up front and feeding it to groff means
that \*(.T exposed to the user what output encoding was being
targeted, so a document could make use of this datum, which would be
impossible if that knowledge were unavailable until grotty was run.)

Anyway, fundamentally re-engineering nroff.sh is far more ambitious
than what I'm trying to address here.

> There also remains the matter of "fallbacks.tmac", which at least
> documents its purpose as "generic", by which I think we are to assume
> output-driver independent.

Yeah, files that are also used outside of grotty contexts need to be
separate from grotty-specific initializations.  The question is how
many initialization .tmac files grotty needs; and, if more than one,
how to communicate to the user the practical uses for including only
some of them.

> The comments at the tops of fallbacks.tmac and tty-char.tmac do appear
> to articulate coherent objectives, but I'm not sure we (and I include
> myself in that pronoun since I've mucked about with both) have hewed to
> them as reliably as we should.

This may hearken back to my point at the top of this email: if no
user-facing documentation tells document authors in what situations
they might want one file or the other or both, it's unlikely any
established workflows take these divergent objectives into account.
So violating the separation isn't breaking anyone's workflows (at
least, for that subset of users who are exercising recent unreleased
groff code).

> Colin Watson's feedback as man-db maintainer might be helpful here.

I welcome all feedback.  But since man-db appears to call nroff for
terminal display, it always gets both files.  So seemingly from a
man-page POV, the files may as well be seen as monolithic.