(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.robin...@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.
