Re: desired .Bk semantics?

[Ingo Schwarze <schwarze@usta.de>]

Hi Kristaps,

Kristaps Dzonsons wrote on Sat, Jul 03, 2010 at 06:24:47PM +0200:

> I propose the following.  I've enclosed a patch that demonstrates this.
> First, I disabled `Bk' completely.

I disagree: That is going too far.

Like that, you lose the possibility to keep non-optional arguments
together on the same line.  Consider, e.g.

.Nm cut
.Bk -words
.Fl b Ar list
.Ek
.Op Ar n
.Op Ar
.Nm cut
.Bk -words
.Fl c Ar list
.Ek
.Ar

I admit in this case this is not critical because the keep is near
the beginning of the line, but this is how it should be written,
and such necessities can also arise later on the line,

Thus, do not rip .Bk out completely.
It should be available for the rare cases where is is needed,
and it is a standard mdoc(7) macro we cannot just drop.

> Second, when `Op' or `Oo' is encountered with MDOC_SYNPRETTY (i.e., in a
> SYNOPSIS section or with ".nr nS 1"), spaces are made non-breaking.

I disagree: That is going too far.

Like that, you lose the option to allow breaking in the middle of
an .Op or .Oo group.  Consider, e.g.

.Nm openssl
.Cm gendsa
.Oo
.Fl aes128 |
.Fl aes192 |
.Fl aes256 |
.Fl des |
.Fl des3
.Oc
...

This could get worse when more ciphers are implemented, and ultimately,
it won't fit on one line any more, giving you very ugly output and no way
to fix it.

I don't oppose automatically assuming implied .Bk around .Op and .Oo
tough, as long as they are on one input line, even though troff
historically decided against that.

That's probably the last mail i can send before teardown of the hack
room, and i don't have time to look at your code right now...

Yours,
  Ingo
--
 To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv