Re: Using tbl(1) for structure definitions

[G. Branden Robinson]

Hi Alex,

At 2022-07-30T00:38:13+0200, Alejandro Colomar wrote:
> On 7/29/22 23:08, G. Branden Robinson wrote:
> > At 2022-07-29T17:26:10+0200, Alejandro Colomar wrote:

> Hmm, considering that the amount of multiline comments with 80-char
> terminals is still non-negligible (not in this page, but in all type
> pages), I think I prefer to consistently support them, even when I
> don't need.  That will have 2 side effects: contributors will
> experience a more consistent syntax; and I will support smaller
> terminals with extra-attractive comments.

Okay.  If you trust your contributors to understand that column just for
the comment leader, then I trust you.  :)

> I'll send a v5 with another page, to show that tabs are not good
> enough.  And I'll try to not forget CCing groff@.

It'll be good to have a look.

> > > > I'm really looking forward to killing off another application of
> > > > `PD`.
> > > 
> > > Ok.  T think I'll remove .PD, and leave the extra blank line until
> > > .TS is fixed.  A blank line will not hurt too much.
> > 
> > The fix should be in my next push; I merely got caught in a yak
> > shave called groff_mm(7).
> 
> Nice.  Still, I woudn't make use of it so fast, if the side effect in
> old groff(1) versions was something more than a blank line.

It wasn't.  I was confusing this issue with Savannah #49390.

https://savannah.gnu.org/bugs/index.php?49390

Savannah #43637 is also pretty gross.

https://savannah.gnu.org/bugs/index.php?43637

I rendered all the groff man pages from Git HEAD with groff 1.22.4, with
the `sp` request deleted from the `TS` definition and a fallback
definition of `MR` (just like the one I presented in arguments with
Ingo) in man.local, and observed no pertinent layout problems.

> Poor contributors are unlikely to have latest groff for git HEAD :)

Don't I know it.

Regards,
Branden

signature.asc
Description: PGP signature