Hi, Alex! At 2022-05-21T23:58:57+0200, Alejandro Colomar wrote: > On 5/21/22 17:21, G. Branden Robinson wrote: > > In groff(7), I'm piloting "begin list" and "end list" macros to > > provide a path out of the elaborate page-private macro system that > > the page has used for many years. They are even simpler than TQ. > > > > https://git.savannah.gnu.org/cgit/groff.git/tree/man/groff.7.man#n225 > > I recommend naming them LS/LE (list start, list end), for symmetry > with RS/RE (and slightly with others such as UR/UE. LS also happens > to be a nice name for list.
That's a good idea. I like it. Any other votes or suggestions from the
mailing list?
> > Pretty much the only thing people ever use "PD" to do is to set the
> > inter-paragraph distance zero, and restore it to its previous value.
> > It therefore doesn't need an argument to process. Further, if
> > people _try_ to set the inter-paragraph distance to something larger
> > than 1 line in nroff mode, man-db man(1) will strip the extra lines
> > out.
> >
> > There is thus not much use case for anything but
> > .PD 0
> > and
> > .PD
> > .
>
> Does .PD 0 suffer from the reasons that led to the deprecation of .PD?
Yes, I think so. As I understand it, the HTML devices ("html" and
"xhtml") _are_ the problem in this regard. Or they once were. A quick
experiment reveals that `.PD 0` and `.PD` work fine at least for simple
cases in HTML output. See attachment.
> Or is .PD 0 safe from that and can be used portably for compacting in
> HTML or PDF output?
It should be widely portable. The sin of the `PD` macro isn't its
portability, but its "presentationality", if you will. Almost every
semantic text markup system I've seen, and several presentational ones,
like the Markdown family, has a notion of a "list". man(7) is something
of an outlier in lacking it. By adding one we make the jobs of those
who write tools for interconverting these formats easier.
> > This idea, along with one or two other mild man(7) reforms, is
> > something I've put on the shelf until after we get groff 1.23.0 out.
>
> Do you have an idea of when that can be (1.23.0)?
We're pretty close. Ingo Schwarze and John Gardner have been helpful in
finding portability problems that crept into the build/test procedure.
We've had very recent successful build and "make check" reports on
GNU/Linux, macOS, NetBSD, and OpenBSD.
Bertrand Garrigues, our release manager and official maintainer, has
returned back, which is hugely helpful. He has the knowledge and
permissions to roll out a release to the GNU infrastructure.
I need to write release notes for 1.23.0(.rc2)--I think not having them
for rc1 might account for the near-zero level of feedback we got on that
snapshot. I'd like to go to final as soon as after that as is
reasonable, depending on the severity of reported issues, and then
schedule a point release for 6 months after that.
I strongly prefer time-based releases to feature-based ones. I have a
hard time thinking of things as "done".
Regards,
Branden
signature.asc
Description: PGP signature
