Re: thin_space causes collateral damage in eqn

[Damian McGuckin]

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

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

I noticed. But I had my own copy so no problems.

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

Yes.

> In other words, with its application to ^ and ~ tokens being a bug.

We are on the same page there. It is definitely 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.

Good. My eyes are not so old then.

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

I like your names but adding '_width' is inconsistent with those other
'_space' names so you are changing the status quo which is probably less 
than productive. Then again, maybe we should add '_width' to those other 
names. I will leave that discussion for others.

Bye-bye from Oz - Damian