[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: src/share/man/man9
On Mon, Mar 16, 2009 at 23:05:00 +0100, Joerg Sonnenberger wrote:
> On Mon, Mar 16, 2009 at 10:04:40PM +0300, Valeriy E. Ushakov wrote:
> > On Mon, Mar 16, 2009 at 19:42:42 +0100, Joerg Sonnenberger wrote:
> > > On Mon, Mar 16, 2009 at 09:26:07PM +0300, Valeriy E. Ushakov wrote:
> > > > So i think that when you do the exercise of reinterpreting mandoc
> > > > markup as semantic markup you should assign you abstract semantic
> > > > accordingly.
> > >
> > > I am not "reinterpreting mandoc markup". This is what is specified in
> > > mdoc(7):
> > >
> > > -column This list type generates multiple columns. The number of
> > > col-
> > > umns and the width of each column is determined by the arguments
> > > to the -column list, <string1>, <string2>, etc.
> > Shall we have exegetic discussion of the meaning of "is determined"? :)
> Which part of that sentence is not clear?
Why do you assume that "is determined" means "is determied to be N"? :)
The number of columns that "is determined" by -column <s1> ... <sN> is
N+1 where the first N columns have fixed widths and do not hadle
flowing text and the column N+1 occupies the rest of the page width
and handles flowing text.
If you need to have flowing text or "the rest of available width"
column that is not last then don't abuse -column to be a generic
(Actually, I don't even know if tbl/troff allows you to have a table
that is something like
kinda like tex glue or lout @HExpand).
> > I did the RTFS and I summarized the results in my previous mail. I
> > find my interpretation, supported by troff semantic and actual
> > observable behaviour consistent and useful.
> TFS allows a lot of things, whether they make sense or not.
Troff is not foolproof and it doesn't go out of its way to make sense
out of random input you throw at it, so it's easy to make it do weird
things and then point and laugh at stupid old troff and its "good
In this case, however, understading -column in terms of tabs makes
perfect sense and does the right thing for correct input too. I don't
even care if that was intended by the original author or not :),
though I think it was - it's too natural for troff.
> For example, it will happily break lines if the output is larger
> than the given width.
Don't abuse -column to be a generic purpose table.
> It does not do that incorrectly, which is another hint that it works
> only by chance, not by design.
It wraps the overlong lines exactly to the start of that N+1 column
which existence you deny. :)
> Whether it should have a way to allow variable column size is a
> completely separate discussion
It's not separate. It's a needed feature (this whole thread started
exactly because of it) and it doesn't make sense to leave it out of
discussion. Otherwise we would end up like that physicist from the
joke that invented a formula to predict outcome of horse races for
"spherical horses in vacuum".
> right now it does not.
Right now it already does if you don't insist on interpreting that
admittedly sloppily worded documentation in a specific way that
aritifically rules it out for the sake of .... uhm ... I'm not even
Would you seriously insist that we should discard existing behaviour
that is consistent and practical and introduce (i.e. hack mdoc troff
macros) artificial variable-width-last-column marker to -column
arguments with the sole purpose of the exercise being that the number
of arguments to -column be equal to the number of columns?
uwe%stderr.spb.ru@localhost | Zu Grunde kommen
http://snark.ptc.spbu.ru/~uwe/ | Ist zu Grunde gehen
Main Index |
Thread Index |