Hi, Tadziu! At 2022-07-01T01:10:16+0200, Tadziu Hoffmann wrote: [I wrote]: > > This appears to be because "PI" is a magic token in eqn(1), > > preferentially interpreted even in this context as a shorthand > > for the capital Greek pi symbol; it is therefore replaced with > > a special character escape sequence to access the > > corresponding glyph, which is `\(*P`. > > How do we cope with this problem? > > Quoting the argument works: > > gfont "PI" > > It seems that the parser does not make an exception for eqn > control commands, at least in this case, so "PI" remains PI > and is not replaced by the Greek uppercase pi, just like in > > "PI" + "pi" != PI + pi
Yes. This made a lot more sense once I looked at the sources. The fact that our eqn(1) man page talked about macros (in the eqn language, not *roff) while Kernighan & Cherry's "Typesetting Mathematics" never did led me to assume there more kinds of syntactical objects in eqn than there really are. As penance for my cluelessness I deeply perused that document today. I reckon I'll see if my expertise grows appropriately. One thing that leaped out at me is that many definitions appear to be prepared in eqn's source that could just as easily be done in eqnrc. See the statically initialized arrays starting at <https://git.savannah.gnu.org/cgit/groff.git/tree/src/preproc/eqn/lex.cpp#n126>. I get the feeling that relocating such definitions thus would pay a few benefits. 1. We wouldn't (necessarily) have to list them again in any documentation--or at least not the man page--since eqnrc is present in all installations. 2. They will show eqn users how to do various things without C escape syntax muddying the waters. 3. They'll loosen the coupling between eqn-the-language and this convenient but arbitrary support feature. Architecturally, this appeals to me. A few definitions are already present in eqnrc, whether for device-specific support or to make some definitions "simple" (i.e., their macros fail to expand if they're given arguments). Having the complete eqn dictionary--apart from truly intrinsic language operators or procedures like "over" and "gfont"--available to all users, even those who don't access groff's source code, for study in the relevant implementation language seems like a win to me. Regards, Branden
signature.asc
Description: PGP signature
