Re: thin_space causes collateral damage in eqn

[G. Branden Robinson]

First of all, I predictably forgot my attachment of the retypeset AT&T
eqn user's guide.  So let me fix that.

At 2023-05-17T15:17:55+1000, Damian McGuckin wrote:
> I would agree with Doug 100%

Confidence...increasing...

> > Another parameter, thick_space, has the same effect on ~.
> 
> There is also 'medium space' but it corresponds to nothing explicit or
> deliberate as far as can see.

Huh!

> The documentation says that *_space are only for automatic spacing.

...but automatic spacing applies to anything that has a "type" in GNU
eqn jargon, so this is consistent with Doug's observation.  In other
words, with its application to ^ and ~ tokens being a bug.

> I actually cannot see where the meaning of either '~' or '^' is
> defined in the GNU eqn(1) manual page.

They aren't.  Practically no AT&T eqn features are.

> But maybe my eyes are getting old. Or I should consider Branden's
> comment and take that as a delta against some implied expert's
> understanding of EQN. Sadly I am not an expert yet because I am still
> learning things about EQN after 40 years.

I'll be a happy guy if I can complete the GNU eqn man page, then--it
sounds like it will do a lot of groff users some good.  At least the
ones that care about typesetting math.

> I note that the Plan 9 eqn(1) man page says
> 
>       "Tokens within eqn are separated by spaces, tabs, newlines,
>       braces, double quotes, tildes or circumflexes. Braces {} are
>       used for grouping; generally speaking, anywhere a single
>       character like x could appear, a complicated construction
>       enclosed in braces may be used instead. Tilde ~ represents a
>       full space in the output, circumflex ^ half as much."
> 
> Maybe text along those lines needs to go into GNU eqn's man page.

I think you're right.

In practice, AT&T eqn was a bit Postelian, enough that I had to alter
the K&C document (the one I remembered to attach this time) to get it to
format correctly with GNU eqn.

Exhibit:

.\" Correct missing space after x for GNU eqn.  GBR, 2022.
$lim from {x -> pi /2} ( tan~x) sup{sin~2x}~=~1$

AT&T eqn would apparently let you get away with this:
$lim from {x-> pi /2} ( tan~x) sup{sin~2x}~=~1$

I don't think bug compatibility would serve us well here.  Plenty of
languages permit '-' in identifiers or tokens (like Lisp and *roff).

> One can argue that there needs to be
> 
>       thin_space_user
>       thick_space_user
> 
> if control is needed over those for the user's deliberately defined
> cases.
> 
> That said, they should be called
> 
>       full_space_user
>       half_space_user
> 
> because that is what they technically are. We could just drop the
> '_user' and note in the documentation that they are
> explicitly/deliberately forced into the said equation by '~' and '^'
> respectively.

I like this idea.  "{full,half}_space_width" might be even better.

[...]
> P.S. Sadly Lorinda Cherry passed away a bit over 12 months ago.

I learned that shortly before beginning my work on my little
"retypesetting mathematics" project.  :(

Regards,
Branden

eqnuser-retypeset.pdf
Description: Adobe PDF document

signature.asc
Description: PGP signature