Hi Doug,
Doug McIlroy wrote on Tue, May 01, 2018 at 11:40:50PM -0400:
> Ingo suggested a way to write two equations aligned
> on equals signs, to look rather like this
> shortid = expression1
> longidentifier = expression2
>
> Here's the code
> .EQ
> set column_sep 35
> matrix {
> rcol { xhortid above longidentifier }
> ccol { = above = }
> lcol { expression1 above expression2 }
> }
> .EN
>
> Yes, I've used this trick many times. It's impenetrable to
> read and excruciating to edit.
Fair point indeed.
As Ted suggested, i find it likely that the vertical spacing issue
you talk about can be solved relatively easily outside eqn(1), on
the .EQ macro level.
But the horizontal alignment issue - not knowing at which horizontal
position to put the mark until all equations in the group have been
rendered, but already needing that information for the rendering
of the first equation - may be more serious. Essentially, it may
require two-pass processing (Tadziu mentioned writing positions to
an external file during the first pass, which is of course a very
ugly method, but it may be hard to come up with a better idea that
works in general).
Note that it seems to me that the horizontal alignment problem does
not depend on the particular syntax; it looks like a logical problem
that occurs with any syntax, in particular both with anything based
on multiple .EQ blocks and with the hypothetical single-.EQ solution
using mark/lineup that you wish for. In the latter case, i would
be a bit surprised if the eqn(1) code, at the time of rendering the
tokens around the mark, could already know how long the expressions
before later lineups shall be.
You may think that pile/pile/pile and matrix are able to do it and
produce the correct indentation inside a single .EQ block, so
mark/lineup should also be able to as well. But i fear that misses
the crucial point. The reason why pile/pile/pile and matrix work
seems to be precisely because the tokens are presented out of order
in the source code, column by column, and that is precisely what
you do not want to carry over to your proposed mark/lineup semantics.
Yours,
Ingo
