All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alejandro Colomar <alx@kernel.org>
To: Ingo Schwarze <schwarze@usta.de>
Cc: g.branden.robinson@gmail.com, linux-man@vger.kernel.org, groff@gnu.org
Subject: Re: Using LS/LE
Date: Sat, 29 Aug 2026 14:51:44 +0200	[thread overview]
Message-ID: <apLSc6uhVjBNhtyy@devuan> (raw)
In-Reply-To: <apLD35LsoOqX6fK1@isnote.usta.de>

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

Hi Ingo,

> Date: 2026-08-29 13:34:55+0200
> From: Ingo Schwarze <schwarze@usta.de>
>
[...]
> The mandoc(1) -T man output mode uses
> [...]

Oh, there's a -Tman mode!  That's interesting!  Some years ago,
I wondered whether groff(1) could have a -Troff mode, which would
evaluate the man(7) (or any other -m macros, FWIW) macros without
formatting the document.  This -Tman from mandoc(1) sounds like a
similar (but not same, of course) thing.

[...]
> >      .LS type [compactness [indentation]]
> 
> What is the logical reason for requiring that, to specify the
> indentation, you also need to specify the compactness?

I guess I'd have the same question if it were the other way around, and
this way I expect it's simple to implement (I'd certainly be more
worried if groff(1) attempted to guess the meaning of my argument if I
only pass one of them), so I think I'm okay with it.  Do you have any
ideas for a better interface?

> >             (since groff 1.25) Start (or open) a list.  type is one of
> >             "definition", "enumerated", or "itemized".  compactness is a
> >             Boolean value directing suppression of inter-paragraph
> >             spacing between list items.
> 
> That sounds very confusing.  Does "Boolean" mean: either the string "0"
> or the string "1"?  Or what would "true" or "false" mean?
> Then, "Boolean value directing suppression" sounds vaguely as if "1"
> might mean "suppress", but that's not expressed unambiguously.

Agree.

> Finally, why only *between* list items?  Why not *before each*
> list item?  Would suppressing the vertical spacing before the first
> list item still require .PD 0 *in addition* to "compact"?

The idea, I think, is that if you write '.P' surriounding LS/LS, you'll
get the outer blanks, and if not, you'll get compactness also before
and/or after the list.

[...]
> >             Use IP with a mark argument to represent an
> >             itemized or enumerated list item, and TP for a definition
> >             list item.  Use IP without arguments to associate
> >             successive paragraphs with an existing list item; to these,
> >             inter-paragraph spacing applies even in compact lists.
> 
> Not sure the phrase staring with "to these" should be advertised
> so prominently.  *If* an author chooses to make a list "compact"
> but then kind of contradicts themselves by inserting paragraph
> breaks into individual list items, the behaviour you describe is
> probably what the formatter should do.

I'm not convinced about this detail either.  I think in a compact list
this should not produce a blank line:

	.P
	.LE

But this should:

	.LE
	.P

> But authors ought to be strongly discouraged from doing that.
> When one or more items of your list are so complicated that they
> require more than one paragraph of text, making your list "compact"
> makes no sense in the first place and will result in ugly and
> confusing typography.

+1

> To summarize, after reviewing the design of .LS/.LE, my first
> impression is that it is likely a small-value, small-harm
> addition.  I think i will support them in mandoc(1) -man when
> i find the time, but not emit them from mandoc(1) -T man, at least
> not for many years to come, because the whole point of that output
> mode is dealing with operating systems that use ancient
> manual page formatters, and those are unlikely to support .LS/.LE.

Makes sense.

> Chances are the the deeper scrutiny that will be necessary to
> implement .LS/.LE in mandoc(1) may lead to additional criticism;
> or if we are lucky, it may not.


Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es>

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

  reply	other threads:[~2026-08-29 12:51 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-03 19:21 [PATCH v4 2/4] man/man5/tunables.conf: Document system-wide tunables config DJ Delorie
2026-08-06 14:37 ` Alejandro Colomar
2026-08-06 15:33   ` DJ Delorie
2026-08-06 19:14     ` Alejandro Colomar
2026-08-06 20:17       ` DJ Delorie
2026-08-06 20:31         ` Alejandro Colomar
2026-08-06 20:42           ` DJ Delorie
2026-08-07  2:12             ` G. Branden Robinson
2026-08-07  3:29               ` DJ Delorie
2026-08-07  3:49                 ` G. Branden Robinson
2026-08-07  4:01                   ` DJ Delorie
2026-08-07  4:09                     ` G. Branden Robinson
2026-08-23 12:29               ` Using LS/LE (was: [PATCH v4 2/4] man/man5/tunables.conf: Document system-wide tunables config) Alejandro Colomar
2026-08-23 13:27                 ` G. Branden Robinson
2026-08-23 13:55                   ` Alejandro Colomar
2026-08-23 14:16                     ` G. Branden Robinson
2026-08-23 15:06                       ` Alejandro Colomar
2026-08-23 16:44                         ` G. Branden Robinson
2026-08-23 19:30                           ` Alejandro Colomar
2026-08-23 20:40                             ` G. Branden Robinson
2026-08-23 23:11                               ` Alejandro Colomar
2026-08-24  1:11                                 ` G. Branden Robinson
2026-08-24  2:01                                   ` Using LS/LE Collin Funk
2026-08-24 11:08                                     ` Alejandro Colomar
2026-08-24 11:00                                   ` Using LS/LE (was: [PATCH v4 2/4] man/man5/tunables.conf: Document system-wide tunables config) Alejandro Colomar
2026-08-23 22:31                             ` autotools, was: Using LS/LE Ingo Schwarze
2026-08-24  0:09                               ` Alejandro Colomar
2026-08-29  4:36                               ` G. Branden Robinson
2026-08-29 11:34                                 ` Ingo Schwarze
2026-08-29 12:51                                   ` Alejandro Colomar [this message]
2026-08-29 19:16                                     ` G. Branden Robinson
2026-08-29 21:43                                       ` Alejandro Colomar
     [not found]                             ` <8DE76435-CBDB-42D6-9E0F-9E27291560B6@icloud.com>
2026-08-29  8:42                               ` Using LS/LE (was: [PATCH v4 2/4] man/man5/tunables.conf: Document system-wide tunables config) Alejandro Colomar
2026-08-29  8:45                                 ` Alejandro Colomar
2026-08-29  8:52                                   ` Alejandro Colomar
2026-08-29  9:02                                     ` Alejandro Colomar
2026-08-29  9:39                               ` Ingo Schwarze
2026-08-29 13:10                                 ` configure separate from make or not (was: Using LS/LE) Alejandro Colomar
2026-08-29 15:31                                   ` configure separate from make or not Ingo Schwarze
2026-08-29 20:49                                     ` Alejandro Colomar
2026-08-30 13:17                                       ` Alejandro Colomar

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=apLSc6uhVjBNhtyy@devuan \
    --to=alx@kernel.org \
    --cc=g.branden.robinson@gmail.com \
    --cc=groff@gnu.org \
    --cc=linux-man@vger.kernel.org \
    --cc=schwarze@usta.de \
    /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.