Re: GNU eqn clarifications and reforms (was: EQN - special words)

[Damian McGuckin]

On Wed, 31 May 2023, G. Branden Robinson wrote:

> 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...)

OK, so I can go back to calling a '~' and '^' a full space and a half 
space and assuming that they have widths of 2/7th of an em and 1/6 of an 
em as per the old documentation.

> 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.

That's what I thought but in 1.22.4

        '...'   produces 3 separated dots
        cdots   produces 3 an ellipsis
        cdot    produces 1 dot

all at the same height as a minus sign, i.e. above the text baseline.
Note that cdots is defined in 'lex.cpp' as

        \(md \(md \(md

and I notice that the troff symbol \(md (middot) is defined absolutely 
nowhere, even if the groff \[md] or multiplication do is in groff_char.

> 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.

In 1.22.4, 'delim on' fails.

> 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.

Thanks.

> > >    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.

Scary programming.

> 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.

Sounds like great rationalization.

Ignore what I said about divide. Your idea of putting the definition in 
the user's our initialization file sounds like the way to go when needed.

I agree that 'div' belongs in vector calculus. It is not for \[di].

> > 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.

Got it. I will believe you. I have not delved through the source code to 
anywhere like the level you have.

Thanks - Damian

Pacific Engineering Systems International ..... 20D Grose St, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer