groff
[Top][All Lists]
Advanced

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

Re: Explanations with an EQN User Guide


From: Douglas McIlroy
Subject: Re: Explanations with an EQN User Guide
Date: Tue, 23 May 2023 11:07:46 -0400

The new wording in groff(7) seems to explain everything--a great
improvement. But knowing how it works is not the same as knowing how
to use it.

In the absence of any useful examples, I think a hazard warning in the
user guide is preferable to an explanatory essay.

Maybe tabs in eqn should be officially deprecated. Does anyone disagree?

Doug

On Tue, May 23, 2023 at 12:48 AM G. Branden Robinson
<g.branden.robinson@gmail.com> wrote:
>
> Hi Doug,
>
> At 2023-05-22T20:04:53-0400, Douglas McIlroy wrote:
> > > Basically, [if] a tab occurs within braces, it will be rejected.
>
> This statement of mine was, alas, too general.  A tab within braces will
> be rejected (diagnosed and ignored) if the braces are necessary to
> disambiguate the input.
>
> > Running eqn standalone, I got identical outputs from these
> > two inputs
> >
> > .EQ
> > a<tab>b
> > .EN
> >
> > .EQ
> > {a<tab>b}
> > .EN
>
> So do I.  But I think I know why.
>
> Try the following slightly more complex input:
>
> (Interpret all sequences of more than one space as a tab character.)
>
> .EQ
> { a     b }
> .EN
> .sp
> .EQ
> sqrt { a        b }
> .EN
>
> Like parentheses in the expression "(2+3)", there was no need to push
> anything onto an evaluation stack because you were already at the top
> level.  For the same reason, you can't trick eqn into complaining about
> the nested tab character with:
>
> .EQ
> { { { { a       b } } } }
> .EN
>
> > The tab is passed to groff as \t\,
>
> Yes--but _inside a string definition_ (technically an appendment, a rare
> word that I have impressed into service in groff documentation).
>
> > man 7 groff says \t is "uninterpreted",
>
> groff(7) on Git HEAD hasn't said this for a while.  Its mentions of "\t"
> are as follows.
>
>     The following escape sequences don't take arguments and thus are
>     allowed as delimiters: \space, \%, \|, \^, \{, \}, \', \`, \-, \_,
>     \!, \?, \), \/, \,, \&, \:, \~, \0, \a, \c, \d, \e, \E, \p, \r, \t,
>     and \u.  However, using them this way is discouraged; they can make
>     the input confusing to read.
>
>     The escape sequences \", \#, \$, \*, \?, \a, \e, \n, \t, \g, \V, and
>     \newline are interpreted even in copy mode.
>
>     \t  Interpolate a tab in copy mode.
>
> > yet the tab skips to a tab stop set by .ta.
>
> Because once the string containing is interpolated, it transforms into a
> "real" tab.
>
> > This leaves me totally confused, because groff apparently ignores \t
> > when it doesn't come from eqn.
>
> You can do the same thing eqn is doing.
>
> .ds st foo\tbar
> .tc *
> \*(st
>
> I changed the tab fill character to an asterisk only to show that
> nothing is up my sleeve.  This works the same for me in DWB 3.3,
> Heirloom Doctools, and groff.
>
> Regards,
> Branden



reply via email to

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