[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Using tbl(1) for structure definitions

From: Alejandro Colomar
Subject: Re: Using tbl(1) for structure definitions
Date: Sat, 30 Jul 2022 00:38:13 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.0.2

Hi Branden,

On 7/29/22 23:08, G. Branden Robinson wrote:
Hi Alex!

At 2022-07-29T17:26:10+0200, Alejandro Colomar wrote:
On 7/29/22 15:52, G. Branden Robinson wrote:
I don't think you're abusing it but you are employing some heavy
machinery that brings some limitations with it.  The worst from my
perspective is that using tbl(1) in man pages limits your
flexibility in terms of line length.  Terminal windows can be all
kinds of crazy sizes.

Oh, didn't the Mesopotamians already know about the standard tablet
size of 80x24?  :D

"Thou shalt set your tablet size to 80x24 or larger, but never
smaller; or thou shalt not report a bug if the formatting becomes
unreadable.  Thou shalt not assume your neighbor has a tablet wider
than 80 characters, so thou shalt not write past it."

I think that's what the famous tablets said.

Mmm, so it would be nice to overcome that line intersection problem in
grotty(1).  Maybe for groff 1.24...

Sure; compare:

            u64  mode;     /* Mode          for

            u64  mode;     /* Mode          for

Ah, you want the comments to wrap extra-attractively.  Let me counter by
suggesting that most of the time, the comments should fit on the same
ouput line anyway.

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.

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@.

I'm really looking forward to killing off another application of

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. Poor contributors are unlikely to have latest groff for git HEAD :)



Alejandro Colomar

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]