Re: [mdoc] Bq not terminated by Ta

Hi Ingo,

On Fri Oct 31, 2025 at 5:50 PM CET, Ingo Schwarze wrote:
> onf wrote on Thu, Oct 30, 2025 at 11:23:14PM +0100:
> > I am sure Branden is gonna be happy because I found another questionable
> > behavior of groff's mdoc implementation. When using Bq in a columnated
> > list (aka a table), Bq encloses everything until end of input line in
> > square brackets, rather than just the stuff until next Ta (i.e. column
> > separator). No diagnostics are produced. mandoc does not exhibit this
> > behavior.
> > 
> > Example to reproduce:
> >   .Dd October 30, 2025
> >   .Dt EXAMPLE 1
> >   .Os
> >   .Sh DESCRIPTION
> >   .Bl -column [One] [Two] [Three]
> >   .It Bq One Ta Bq Two Ta Bq Three
> >   .El
>
> Arguably, the groff output
>
>   [One     [Two     [Three]]]
>
> is more correct than the mandoc output
>
>   [One]    [Two]    [Three]
>
> because mandoc mdoc(7) says:
>
>    Block partial-implicit
>      Like block full-implicit, but with single-line scope closed
>      by the end of the line.
>
> and groff_mdoc(7) says:
>
>      The '.Op' macro places option brackets around any remaining
>      arguments on the command line, and places any trailing
>      punctuation outside the brackets.

There is a reason I didn't call it a bug -- I don't know mdoc well
enough to be able to judge that. It just seemed unintuitive and
possibly wrong.

[...]
> 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.

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 >.

Cheers,
onf