Hi,
onf wrote on Fri, Oct 31, 2025 at 08:10:24PM +0100:
> On Fri Oct 31, 2025 at 5:50 PM CET, Ingo Schwarze wrote:
>> I would have to think
>> a bit more about it though as it seems likely this is not the
>> only case where blocks nested badly in unusual ways cause subtle
>> issues, and giving undue weight to one particular mini-issue while
>> glossing over others should probably be avoided.
> I too would expect that other macros that function similarly to Bq
> might exhibit similarly questionable behavior. I reported this one
> because it's simply the one that I ran across. In fact, I just
> tested those and the same behavior is exhibited by Aq, Brq, Dq, Pq,
> Ql, Qq, and Sq; in other words, all of them.
Yes, of course all the callable implicit partial block macros
behave the same way, unless special behaviour was chosen for any
particular one. I silently assumed that as obvious in my original
reply, for example when pointing to the .Op documentation even
though you asked a question about .Bq, not .Op.
What i mean with "not the only case" and "blocks nested badly
in unusual ways" is potential cases where blocks are nested badly
and the breaking macro is *not* a partial block macro. What i mean
is that i'm neither conviced .Ta is the only breaking macro
that can trigger unusual broken-block behaviour, nor that others
do indeed exist. For example, .It might be a candidate to
investigate what happens when it is breaking, as opposed to the
more usual case where it is broken. But there might be even more
than just .Ta and possibly .It.
> By the way, can anyone explain why
> .Aq one
> and
> .Aq Mt one
> produces different output in UTF-8 mode with both groff and mandoc?
>
> Specifically, the former surrounds the text with U+27E8 and U+27E9,
> which my terminal font (DejaVu Sans Mono) renders as ( and ), whereas
> the latter is surrounded with ASCII 3C and 3E, i.e. < and >.
Yes, .Aq requests angle brackets, and U+27E8 / U+27E9 (MATHEMATICAL
ANGLE BRACKETS) is the traditional way how groff renders angle
brackets - i never considered whether that is the best rendering,
other candidates might be U+2329 / U+232A or U+3008 / U+3009.
Unicode is such a large garden full of wonderful plants.
The main reason for not wondering which rendering is best
is that it's unclear what use case .Aq is intended for in the
first place in a manual page. As mdoc(7) says:
Aq line
Enclose the rest of the input line in angle brackets. The only
important use case is for email addresses. See Mt for an example.
In the important use case ".Aq Mt", however, it is clear which
rendering is the right one because using U+003C / U+003E is
dictated by the SMTP RFC, see the angle-addr production in
RFC 5322 section 3.4.
For that reason, using U+003C for Aq Mt is explicitly implemented,
see for example line 1599 in
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mandoc/mdoc_term.c?annotate=1.286
and the corresponding 2015 commit
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mandoc/mdoc_term.c#rev1.202
Why isn't that documented? Well, generally the mdoc(7) manual page
does not document rendering because mdoc(7) is not a presentational
language. Instead, that manual page documents syntax and semantics
because mdoc(7) is intended as semantic markup, so authors should
focus on what the markup they write *means* rather they how it will
be rendered. Besides, rendering by definition depends on the output
device. (Admittedly, sometimes both the language and the documentation
stray into presentational territory, sometimes for good reasons,
sometimes without very good reasons).
Yours,
Ingo
