Re: [PATCH v1] CONTRIBUTING.d/style/c: Add coding style for the example programs

["G. Branden Robinson" <g.branden.robinson@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3415 bytes --]

Hi Alex,

At 2025-02-09T00:59:50+0100, Alejandro Colomar wrote:
> On Sat, Feb 08, 2025 at 05:46:19PM -0600, G. Branden Robinson wrote:
> > _If_ you advise the use of tab characters _only_ when filling is
> > disabled, as, apropos of the Subject line, is the case in
> > (displayed) code examples, you should be fine.
> 
> Yes, I'm proposing using tabs exclusively within EX/EE.
> 
> > However, you will get 8 character cells per tab stop and I am _not_
> > sure it's portable to expect, or to try to configure, anything else.
> 
> Are you sure?  I'm getting 5 characters per cell, which is what has
> prevented me from doing it more happily.  I would have done it already
> if I had seen 8 chars-per-tab.

Good thing I looped in the groff list; this way more people got to see
me make a fool of myself.

You're right.  Here's why.

https://git.savannah.gnu.org/cgit/groff.git/tree/tmac/an.tmac?h=1.23.0#n162

My days of furious hacking on the man(7) macro package seem mostly to be
in the past, and I'm spending much more time on GNU troff itself of
late.  So I insensibly crafted a demonstrator for the formatter's own
behavior, not incorporating that of the macro package.

> Why am I not seeing 8-char indents?

Because the package redefines the tab stops.

This rears the head of the portability beast a bit higher.

Famous Original Doug's man(7) in Seventh Edition Unix also set the tab
stops at every half-inch.

https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/lib/tmac/tmac.an

So does Heirloom Doctools.  So does mandoc(1).

Neatroff doesn't ship its own man(7) implementation, and Plan 9 and
Solaris 10 troffs, and whatever other System V troffs still exist,
I'll wager have no relevance to the Linux man-pages project.

Fortunately grotty(1)'s different idea of how wide a tab stop is doesn't
pose a problem.  It renders a page as a rectangular grid of character
cells, populates those cells where the formatter (which knows the
document's tab stops) tells it to, then, if it's been given the `-h`
option, it uses 8-column tab stops to optimize output.  But, provided
the Unix terminal driver's tab stops are also configured to every 8
columns,[1] this causes no alteration of the output.

This works out okay because there's no such thing as a "tab stop" in the
formatter's page description language.

This half-inch tab stop default would seem to foreclose the possibility
of using hard tabs for code examples in your man page sources, unless
you want to depart from Ingo's and my man(7) portability advice
regarding the use of formatter requests.

Regards,
Branden

[1] ...which is almost always true, and while traditionally this was
    configurable on Unix systems,[2] it's possible that userland and/or
    terminal driver support has bitrotted to nonfunctionality on
    Linux-based systems, or was never implemented in the first place.

    See subsection "Tabs and Initialization" of terminfo(5).

[2] ...because of the long shadow cast by typewriters (the original Unix
    terminal devices) and the corresponding more "manual" and
    labor-intensive table composition procedures they required.
    Similarly, newspaper-style page composition with "cut" and "paste"
    operations involving scissors and adhesive are fading from memory--
    as is the Aldus PageMaker product that largely killed the practice.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]