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 --]
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox