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

["onf" <onf@disroot.org>]

Hi Branden & Alex,

On Sun Feb 9, 2025 at 12:46 AM CET, G. Branden Robinson wrote:
> [...]
> At 2025-02-08T23:57:07+0100, Alejandro Colomar wrote:
> > On Sat, Feb 08, 2025 at 11:44:43PM +0100, Alejandro Colomar wrote:
> > > Personally, I prefer tabs for actual programming.  But for manual
> > > pages, we can live with 4 spaces for $reasons.
> > > 
> > 
> > [...]
> > 
> > > +Description
> > > +    Indentation
> > > +	Use 4 spaces.  Ideally, tabs would be preferred; however, they
> > > +	cause 5 spaces in manual pages, which is weird, so we use 4
> > > +	spaces.
> > 
> > On a side note, Branden, I've considered changing the manual pages'
> > EXAMPLES' source code to use tabs, and let the formatter do whatever
> > it wants.  Do you have any opinion on that?
>
> The behavior of input tab characters is well-defined in *roff, but
> defined _weirdly_ to most people's sensibilities when filling is
> enabled.  I won't quote the documentation here, merely point to it.
>
> https://www.gnu.org/software/groff/manual/groff.html.node/Tabs-and-Leaders.html
> [...]

TL;DR:
With the default settings, a tab essentially translates into a
horizontal motion. What this means is that when filling is on
and you have text like this:
  int main(int argc, char **argv) {
  \tif (argc != 2 || strcmp(argv[1], "-h") == 0) {
  \t\tfprintf(stderr, usage, argv[0]);
  \t\treturn argc != 2;
  \t}
  \treturn 0;
  }

it ends up like this:
  int  main(int  argc, char **argv) {         if (argc != 2 || str‐
  cmp(argv[1], "‐h") == 0) {                 fprintf(stderr, usage,
  argv[0]);                 return argc != 2;         }         re‐
  turn 0; }

This is because tab stops are related to the beginning of a paragraph
rather than the beginning of an output line as one would expect.

The desired behavior can be enabled with the request .linetabs,
but this is groff-specific and not supported by other troffs.

~ onf