All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alejandro Colomar <alx@kernel.org>
To: "G. Branden Robinson" <g.branden.robinson@gmail.com>
Cc: groff@gnu.org, linux-man@vger.kernel.org, bug-ncurses@gnu.org
Subject: Re: Proposed v2: revised man(7) synopsis macros
Date: Sun, 5 May 2024 14:41:44 +0200	[thread overview]
Message-ID: <Zjd-jgQ_VFTidbnT@debian> (raw)
In-Reply-To: <20240503203126.uk32l2r3yp5gwltp@illithid>

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

Hi Branden,

On Fri, May 03, 2024 at 03:31:26PM -0500, G. Branden Robinson wrote:
> At 2024-04-26T11:32:06+0200, Alejandro Colomar wrote:
> > > My questions:
> > > 
> > > A.  Does anyone object to me committing this change to groff's
> > >     master branch?  It will of course require a NEWS item, which I
> > >     will write.
> > 
> > Acked-by: Alejandro Colomar <alx@kernel.org>
> > 
> > > B.  Does this look enticing enough to any documenters of C libraries
> > >     for you to adopt it?
> > 
> > This one at least.  :-)
> 
> I've pushed this.
> 
> $ head -n 9 tmac/an-ext.tmac
> .\" groff extension macros for man(7) package
> .\"
> .\" Copyright (C) 2007-2024 Free Software Foundation, Inc.
> .\"
> .\" Written by Eric S. Raymond <esr@thyrsus.com>
> .\"            Werner Lemberg <wl@gnu.org>
> .\"            G. Branden Robinson <g.branden.robinson@gmail.com>
> .\"
> .\" You may freely use, modify and/or distribute this file.
> 
> Share and enjoy!

Thanks!

I'm trying it already in liba2i, since it's a project that I don't
expect to use until 1.24.0 is out.

Here's some feedback:

-  Hardcoded line widths have an interesting feature: the author decides
   the breaking point, which is interesting to highlight differences
   between similar functions.  See for example printf(3):

     int printf(const char *restrict format, ...);
     int fprintf(FILE *restrict stream,
                 const char *restrict format, ...);
     int dprintf(int fd,
                 const char *restrict format, ...);
     int sprintf(char *restrict str,
                 const char *restrict format, ...);
     int snprintf(char str[restrict .size], size_t size,
                 const char *restrict format, ...);

   As you can see, the breaking point clearly shows the differences
   between all of those, and leaves the common part in a separate line.

   Still, this is not the common case, and most pages would benefit of
   this SY.  I'm just mentioning here to note that old hard-coded BI
   still has its place in some pages.  I will probably never use SY in
   printf(3).

-  I found an inconsistent break point:

   Type‐generic macros
     int a2i(TYPE, TYPE *restrict n, const char *s,
             char **_Nullable restrict endp, int base, TYPE min, TYPE max);

     int a2s(TYPE, TYPE *restrict n, const char *s, char **_Nullable re‐
             strict endp, int base, TYPE min, TYPE max);
     int a2u(TYPE, TYPE *restrict n, const char *s, char **_Nullable re‐
             strict endp, int base, TYPE min, TYPE max);

   Why is 'restrict' hyphenated in two cases, but not in the first one?!
   The source is:

alx@debian:~/tmp/groff/SY$ cat restrict.3 
.TH a s d f
.SH Name
restrict \- gets broken
.SH Type-generic macros
.B int
.SY a2i (
.B TYPE,
.BI TYPE\~*restrict\~ n ,
.BI const\~char\~* s ,
.BI char\~**_Nullable\~restrict\~ endp ,
.BI int\~ base ,
.BI TYPE\~ min ,
.BI TYPE\~ max );
.YS .
.P
.B int
.SY a2s (
.B TYPE,
.BI TYPE\~*restrict\~ n ,
.BI const\~char\~* s ,
.BI char\~**_Nullable\~restrict\~ endp ,
.BI int\~ base ,
.BI TYPE\~ min ,
.BI TYPE\~ max );
.YS .
.B int
.SY a2u (
.B TYPE,
.BI TYPE\~*restrict\~ n ,
.BI const\~char\~* s ,
.BI char\~**_Nullable\~restrict\~ endp ,
.BI int\~ base ,
.BI TYPE\~ min ,
.BI TYPE\~ max );
.YS
alx@debian:~/tmp/groff/SY$ man ./restrict.3 | cat
a(s)                                                                       a(s)

Name
     restrict - gets broken

Type‐generic macros
     int a2i(TYPE, TYPE *restrict n, const char *s,
             char **_Nullable restrict endp, int base, TYPE min, TYPE max);

     int a2s(TYPE, TYPE *restrict n, const char *s, char **_Nullable re‐
             strict endp, int base, TYPE min, TYPE max);
     int a2u(TYPE, TYPE *restrict n, const char *s, char **_Nullable re‐
             strict endp, int base, TYPE min, TYPE max);

f                                      d                                   a(s)


I would suggest never breaking anything between SY/YS.  Or do you want
me to use \% where appropriate?  It's a bit of work that I'd prefer to
avoid.

Have a lovely day!
Alex

> Regards,
> Branden


-- 
<https://www.alejandro-colomar.es/>
A client is hiring kernel driver, mm, and/or crypto developers;
contact me if interested.

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

  reply	other threads:[~2024-05-05 12:41 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-26  5:59 Proposed v2: revised man(7) synopsis macros G. Branden Robinson
2024-04-26  9:32 ` Alejandro Colomar
2024-05-03 20:31   ` G. Branden Robinson
2024-05-05 12:41     ` Alejandro Colomar [this message]
2024-05-05 12:44       ` Alejandro Colomar
     [not found]         ` <20240505135453.4rxsqe3so7347mli@illithid>
     [not found]           ` <ZjeTilIR86sBYrtI@debian>
2024-05-05 14:28             ` Alejandro Colomar
2024-05-05 14:32               ` G. Branden Robinson
2024-05-05 14:45                 ` Alejandro Colomar
2024-04-26 21:54 ` Lennart Jablonka
2024-04-26 22:31   ` Undeprecating man(7)'s `HP` macro? (was: Proposed v2: revised man(7) synopsis macros) G. Branden Robinson
2024-04-29  8:39 ` Proposed v2: revised man(7) synopsis macros G. Branden Robinson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Zjd-jgQ_VFTidbnT@debian \
    --to=alx@kernel.org \
    --cc=bug-ncurses@gnu.org \
    --cc=g.branden.robinson@gmail.com \
    --cc=groff@gnu.org \
    --cc=linux-man@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.