At 2023-06-01T12:06:47+1000, Damian McGuckin wrote: > I am worried my new EQN documentation is not going to be relevant to > heirloom (Plan9's?) TROFF/EQN and NEATROFF/NEATEQN. I can just put in > a warning.
I don't know much about other eqn implementations, but I've never
heard/read that any of them innovated in any way beyond the feature set
of Version 7 Unix eqn. (I haven't specifically researched this issue,
but I do read everything I can get my hands on about *roff and I would
expect to have blundered into _something_ over the past 5-6 years...)
Further, GNU eqn is almost completely backward compatible with V7 eqn
with respect to input. There are two exceptions I know of, now both
clearly documented in the eqn(1) page in groff Git HEAD.
1. An input token of "..." puts an ellipsis on the text baseline in GNU
eqn, but on the math axis in V7 eqn.
2. "delim on" turns (back) on any previously specified equation
delimiters in GNU eqn, but in V7 eqn sets up 'o' and 'n' as
delimiters of the left and right ends of an "inline" equation.
I'm not saying you should feel bound to cover Plan 9, Heirloom Doctools,
or Neat eqns, but if you do so and if I'm right, it shouldn't be hard to
identify GNU extension features as such when you discuss them.
Certainly if I identify any more extensions/incompatibilities, I will
add them to the man page so that it might continue to be a useful
resource to you.
> > Right now in Git HEAD, eqn(1) documents the "thin space" as follows.
>
> > [...]
> > thin_space This amount of space is automatically inserted
> > after punctuation characters. It also
> > configures the width of the space produced by
> > the ^ token (17).
>
> OK. But shortly you are going to break that connection so I can retain
> the original eqn definition of both '~' and '^'?
Yes, but where "shortly" is as a point in time I cannot identify. With
any luck, Bertrand will have some cycles soon and we can tag the head of
master as final. That would be my recommendation to him: there have
been nothing but updates to documentation files since RC4, and my
appetite for squeezing in fixes from my private branch diminishes the
more that RC recedes into the past.
> > eqn sets up spacings and styles as if by the following commands.
> >
> > chartype "letter" abcdefghiklmnopqrstuvwxyz
> > chartype "letter" ABCDEFGHIKLMNOPQRSTUVWXYZ
> > chartype "letter" \[*a]\[*b]\[*g]\[*d]\[*e]\[*z]
> > chartype "letter" \[*y]\[*h]\[*i]\[*k]\[*l]\[*m]
> > chartype "letter" \[*n]\[*c]\[*o]\[*p]\[*r]\[*s]
> > chartype "letter" \[*t]\[*u]\[*f]\[*x]\[*q]\[*w]
> > chartype "binary" *\[pl]\[mi]
> > chartype "relation" <>\[eq]\[<=]\[>=]
> > chartype "opening" {([
> > chartype "closing" })]
> > chartype "punctuation" ,;:.
> > chartype "suppress" ^~
>
> What happened to times (= troff's \(mu)? Isn't it binary too? The
> source code says it is a binary as it also says about '+-' and 'cdot'.
Yes, this is something I've been learning about just this week myself.
The difference here is that the foregoing is a table of spacing (and
style) type assignments to _groff characters_ (ordinary or special).
"times" is an eqn macro. It's defined like this:
define "times" ! type "binary" \[mu] !
...except this definition doesn't actually take place in an eqnrc file
or anything like that, but initialized directly into a C++ data
structure.
https://git.savannah.gnu.org/cgit/groff.git/tree/src/preproc/eqn/lex.cpp?h=1.23.0.rc4#n217
Someday I want to experiment with moving all of these built-in macro
definitions into the eqnrc file, with interesting consequences for
anyone who runs eqn with the '-R' flag.
At any rate, "chartype" seems to be just syntactic sugar for iterated
"type" commands, as follows.
chartype "CLASS" abc
becomes
type "CLASS" "a"
type "CLASS" "b"
type "CLASS" "c"
where a, b, c, are ordinary or special groff characters.
> Should we do the same for a '/'. Hmmm. That might be too tough!!
Maybe
define divide ! type "binary" \[di] !
or
define dividedby ! type "binary" \[di] !
If eqn has gotten by this long without this definition, I'm not sure a
case for it as a built-in is strong. But certainly anyone using eqn to
compose a text on elementary arithmetic could employ the above as part
of their document setup.
> ++ (Just to add to your workload) We really need 'divide' as a keyword
> ++ to yield the '\[di] or \(di symbol. Doug, what do you think? That
> troff symbol has been around for 40+ years. Maybe it is time to get it
> added?
I'm not militantly opposed, unless someone proposes to name the macro
"div", which I would vigorously defend as belonging to the domain of
vector calculus.
.EQ
define div ! type "operator" { bold "div" } !
div bold a = { partial { a sub 1 } over { partial x } }
+ { partial { a sub 2 } over { partial y } }
+ { partial { a sub 3 } over { partial z } }
.EN
I emerged from my coffin once to take a fluid mechanics course, and
Professor Navier stokesed me through the heart, leaving a scar...
> What about == and !=? Aren't they relations too?
They are. But they are defined as macros that do the work of
specifying their GNU eqn spacing types.
> Mathematically, they are (I believe) a relational predicate but in
> terms of programming languages, they are called an operator.
> Confusing!
When I think about this stuff I keep grasping on the one hand for
algebraic groups, and "reductions" from computational grammar on the
other, coming to no enlightenment.
An inadequate education is a painful thing sometimes.
Regards,
Branden
signature.asc
Description: PGP signature
