From: Alejandro Colomar <alx@kernel.org>
To: "G. Branden Robinson" <g.branden.robinson@gmail.com>
Cc: Ingo Schwarze <schwarze@usta.de>,
linux-man@vger.kernel.org, groff@gnu.org
Subject: Re: Using LS/LE
Date: Sat, 29 Aug 2026 23:43:18 +0200 [thread overview]
Message-ID: <apNRtf5j8TZj83Bm@devuan> (raw)
In-Reply-To: <20260829191639.p43vvljsfy2vnxo5@illithid>
[-- Attachment #1: Type: text/plain, Size: 3010 bytes --]
Hi Branden,
> Date: 2026-08-29 14:16:39-0500
> From: "G. Branden Robinson" <g.branden.robinson@gmail.com>
>
[...]
> > > 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.
>
> I know of no troff that permits this. In interpretation mode (that is,
> "not copy mode"), interpolation and transformation of tokens to nodes
> are both operations that occur at the earliest possible opportunity
> while interpreting the input stream.
>
> In the past year or so I have revised groff's Texinfo manual to give the
> formatter's internals better coverage.
>
> ---snip---
[...]
> ---end snip----
>
> GNU troff's ability to recursively dump string/macro/diversion,
> user-defined character, and pending output line contents as a forest of
> JSON nodes was a major new feature of groff 1.24.
>
> It's not the same thing by any means as a "wholly macro expanded
> document", but given how dynamic a language *roff is, I'm not sure the
> goal you had in mind is possible. A language theorist might be able to
> help me devise a proof one way or the other.
>
> Nevertheless, the recursive node dumping feature, as with other new
> debugging requests in groff 1.24, forces the formatter to disclose the
> truth about its internal state to a degree unprecedented in *roff.
>
> (I'll just be shampooing out the pomade and taking this plaid blazer off
> now, thanks.)
I'll keep poking you about it from time to time, hoping some day you'll
have the internal tools to implement this. :)
[...]
> Description
> The Blertch language supports the following operators.
>
> a + b
> a - b
> a * b
> a / b
> a % b
>
> It also supports the unary plus and minus operators.
>
> +a
> -a
>
> Operator overloading is not implemented.
>
> Blertch language reference 2026‐08‐29 blertch(7)
>
> I can imagine a counterargument.
>
> "But why support interrupting the list that way? It's _really_ two
> lists, so the document author should have to close off the first list
> with `LE`, do their 'interrupting' paragraph, then start a new list with
> `LS`."
Indeed, I believe this is two lists.
> I say no.
>
> The purpose of the macro package is to serve the technical writer and
> aid them to communicate. It is not to serve the HTML/XML weenie who
> wants all their tags nested in some canonical fashion. Sometimes,
> technological constraints will propagate backward to our language
> designs. But that's a phenomenon to be regretted, not leaned into.
Hmmmm, I'm not convinced we should support this, but I don't care too
much about it either.
Have a lovely night!
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 21:43 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
2026-08-29 19:16 ` G. Branden Robinson
2026-08-29 21:43 ` Alejandro Colomar [this message]
[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=apNRtf5j8TZj83Bm@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