groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [TUHS] Re: symbols in eqnchar


From: G. Branden Robinson
Subject: Re: [TUHS] Re: symbols in eqnchar
Date: Wed, 5 Jul 2023 20:02:58 -0500

Hi Damian,

At 2023-07-06T05:56:40+1000, Damian McGuckin wrote:
> On Wed, 5 Jul 2023, G. Branden Robinson wrote:
> 
> > > As far as I can tell, the EQN
> > > 
> > >   include
> > > 
> > > does not honour the GROFF_TMAC_PATH search path. I think I would
> > > to see it default to
> > > 
> > >   . : the site-tmac directory : the standard tmac directory
> > > 
> > > but that might be a dumb idea. What does anybody else think?
> > 
> > I think it's a pretty good idea.  While eqn definitions aren't *roff
> > macro files, they're pretty close.
> 
> There is already a precedent. 'eqnrc' lives there.

True.  Ordinarily I wouldn't be thrilled with that precedent--but as you
note below, eqnrc _is_ legitimate *roff input (and even a valid macro
file under the definition of "*roff input that does not produce
output").  It seems to be GNU eqn's copy/include feature that is a bit
of an outlier here.  The fact that it has 2 names suggests to me that it
may be a feature inspired by an external source.

If I were coming at the matter from scratch I'd probably move the
hyphenation pattern files and the former "fixmacros.sed" to directories
parallel to tmac/.  But I say "former" in the latter case because we
don't even ship it anymore.  I feel a sudden hankering to drop it from
the repo.

> > Even if we don't re-use GROFF_TMAC_PATH for this purpose, we could add
> > an `-I` option to GNU eqn and have groff(1) pass any `-I` option it is
> > given along to eqn.  Precedent comes from groff(1):
> > 
> >    -I dir
> >        Works as troff's option (see below), but also implies -g and -s.
> >        It is passed to soelim(1) and the output driver, and grn is
> >        passed an -M option with dir as its argument.
> 
> Yes. That will still be a long name and there is not much difference between
> 
>   groff ... -e -I /usr/local/share/groff/site-tmac/ document-with-include
> or
>   groff ... -e /usr/local/share/groff/site-tmac/eqnrc.local 
> document-no-include
> 
> Long winded. I prefer a default search path and I just do
> 
>       groff .... -e document-with0include

Fair.

> > We could consider making the inclusion parser more strict.  It
> > already ignores lines that start with ".EQ" and ".EN".  We could
> > make it use the same rules that input reading already applies,
> > ignoring everything _except_ lines between ".EQ" and ".EN".
> 
> > A user could then comment the file with troff comments outside of
> > .EQ/.EN (which already don't work within eqn input), or even with
> > plain text.
> 
> That would work for me. But disruptive as you note.
> 
> > This would be a disruptive change, but to a feature that is already
> > a GNU extension and one that is a bit hard to use because of the
> > inflexibility of file name resolution, as you noted above.
> > 
> > To aid users to make the transition, we could have GNU eqn throw a
> > warning diagnostic if it finished reading an `include`d file without
> > finding any eqn input in it.
> > 
> > The result might be a net win.
> 
> You could also read
> 
>       $HOME/.eqnrc
> 
> immediately after you read the site-wide 'eqnrc' and stick all the
> definitions you like in there. And 'eqnrc' does support comments.
> 
> That is non-disruptive.

Yes.  But less flexible for different documents that might want to use
different/conflicting dialects of eqn (essentially, different eqn macro
definitions).

> > I may be on the side of the engineers rather than the Unix/OS nerds.
> 
> I lnow a lot of really wise Unix/OS nerds.

So do I!  Maybe I spill too many electrons complaining about the ones
that aren't...

> OK. I had missed that one in my search. It was on Wikipedia. It is
> quite interesting that EQNCHAR has all the other ones covered except
> two tildes about an equals sign.

My guess here is that typesetter character repertoire played a role.

> > My conjecture is that its use is not standardized and its meaning
> > should be presented before it is employed.  That does make it harder
> > for us to supply a predefined macro name that gives it a mellifluous
> > name for reading aloud.
> 
> I can live with
> 
>       =dot

In your new eqn user's guide, you might spell out the fact that "wig" is
short for "wiggle".  My brain failed to come up with that expansion,
and struggled to figure out how characterizing a tilde as a "wig" over
another glyph was ever widespread mathemathical parlance.  Perhaps I
have suffered from overexposure to a recent U.S. president.

Regards,
Branden

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]