Re: [Groff] Proposed equation processor additions

[Dean Allen Provins]

Werner:

On Sat, Feb 19, 2005 at 07:38:30AM +0100, Werner LEMBERG wrote:
> 
> > Has anyone tried the EQN processor additions that I submitted 3
> > weeks ago, and have any experimenters uncovered any problems?
> 
> I've now carefully read your sample_data document, without trying the
> examples yet.  A minor thing which slightly disturbs me is that I
> always have to use a formatting argument as the first element of
> rmatrix.  What do you think of using an optional `col' keyword for
> that purpose?  Originally, `col' is equal to `ccol', but this fact
> isn't properly described in the original eqn documentation, so it
> might be a good candidate for `abusing' it.
> 
>   rmatrix "{"
>     [ col "{" column_specification "}" ]
>     "{" row1 "}"
>     "{" row2 "}"
>     ...
>   "}"
> 
> Thus,
> 
>   rmatrix {
>     { a b }
>     { c d }
>   }
> 
> would be equal to
> 
>   rmatrix {
>     col { l l }
>     { a b }
>     { c d }
>   }
> 
> I could also imagine to make the proposed `col' keyword accept a
> string of column formatters instead, similar to tbl:
> 
>   col "ll"
> 
> This avoids the introduction of the new keywords `c', `l', and `r'.

If I understand correctly, you would like the format line to be
optional, but if specified to be preceded by the work "col".  As an
option, the second format statement above might also be used (col "ll").

I'll have to look carefully at my code to see how to make such a change.
Currently, I'm checking the row number to see if it should be a format
description or not.  However, I don't see why your suggestion could not
be employed in principle.

> 
> BTW, could you integrate the rmatrix stuff directly into eqn.y?  How
> much work is it?

This might be a LOT more work.  I specifically chose to minimize the
impact of my code on James' work for two reasons:

        My C++ is somewhere past novice, but not yet at an intermediate
        stage.  So I thought 'tacking' my code on would ensure that I
        didn't muck up his.

        I didn't understand his code, but I must admit that I didn't
        spend a lot of time studying it.  I chose to get the job done in
        a manner that I knew would work, as I had some experience with
        (f)lex in previous projects.

If you insist, then I'll spend some time on James' code to see how it
might be done.  Note that I'm away for a week, and MAY (if I'm lucky) be
re-integrated into the workforce upon my return.  If that doesn't
happen, then I'll certainly have a look.

>     Werner


Dean

-- 
                                 Dean Provins
                            50.95033N, 114.03791E
                           address@hidden
                         address@hidden
                  KeyID at at pgpkeys.mit.edu:11371: 0x9643AE65