On Wed, 31 May 2023, G. Branden Robinson wrote:
I assume that thin space is the '^' token.
For groff 1.22.4 and earlier, this is basically true, but Doug requested
that we separate the "thin space", which is in GNU eqn terms an amount
of spacing used in automatic adjustments, from the '^' token. I have
implemented this (with a complementary separation for the "thick_space"
and '~') in my private branch for merge to master after we release
1.23.0.
This is the subject of <https://savannah.gnu.org/bugs/?64216>.
OK. Got it. I will tweak my new User's guide.
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. Then again, the old EQN user's guide never knew that GNU's eqn
would be in the mix.
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 '^'?
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'.
Should we do the same for a '/'. Hmmm. That might be too tough!!
++ (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?
What about == and !=? Aren't they relations too?
I have yet another reformatory proposal to make about this list.[2]
And what the man page calls a relation is a relational operator or a
more precisely a relational predicate but that is overly strict
mathematically for a man page.
Mathematically, they are (I believe) a relational predicate but in terms
of programming languages, they are called an operator. Confusing!
Agreed; the current language,
relation relation such as "="
...could really use improvement here. I'll fix that...
...and, having done that in my working copy, I'm attaching fresh
versions of eqn(1) in source and PDF (with embedded fonts this time).
Beauty!!
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
