Re: [Groff] mdoc(7) interpretation differences (maybe groff bug)

[Steffen Nurpmeso]

Hey, Ingo, Werner, list,

Ingo Schwarze <address@hidden> wrote:
 |Werner LEMBERG wrote on Sat, Nov 08, 2014 at 02:19:38PM +0100:
 |> Steffen Nurpmeso wrote:
 |>> [...] i stumbled over a interpretation difference (full source
 |>> attached):
 |>> 
 |>> source:
 |>>   .It Fn at_quick_exit , Fn _atexit
 |>>   groff and mandoc agree.
 |>>   .It Fn at_quick_exit , _atexit
 |>>   Only mandoc gets that right.

 |>> From my understanding of the manual
 |
 |> Where have you read this?
 |
 |I suspect Steffen is talking about this paragraph in the mdoc(7)
 |manual from the mandoc distribution:

Indeed i didn't (well yes i also read that) but explicitly looked
into groff_mdoc (when improving the parser on friday).  For one

 Note that any call to another macro signals the end of the `.Fn'
 call (it will insert a closing parenthesis at that point).

No other macro happens, and two we have

  All content macros are capable of recognizing and properly
  handling punctuation, provided each punctuation character is
  separated by a leading space.

and

  The punctuation is not recognized and all is output in the font
  used by `.Ar'.  If the punctuation is separated by a leading
  white space:

                 .Ar sptr , ptr ) ,

I agree on fuzziness.
(Luckily the mdoc(7) syntax is so inherently crude and nasty that
it maybe doesn't matter at all even after two decades, since noone
ever tried to be more complicated than necessary.)

 |MACRO SYNTAX

 |Note that the text is somewhat fuzzy.  It talks about *many* in-line
 |macros and doesn't say which ones this applies to.  The reason for
 |the fuzziness is that i never found the time time to investigate
 |all the cases, even though i investigated many of them.

 |I certainly wouldn't recommend putting multiple function names on
 |one macro input line; i'm not really surprised that handling turns
 |out to be implementation dependent.  The syntax of the .Fn macro
 |is already fairly complicated:  one mandatory argument, then zero
 |or more optional arguments with semantics differering from the
 |semantics of the first argument.
 |
 |Indeed, mandoc does treat .Fn as an in-line macro (in particular
 |outside the SYNOPSIS).  But i never thought about what should
 |happen when .Fn is interrupted by punctuation.  The mandoc
 |behaviour of reopening a new scope afterwards is not intentional,
 |it's just what the code (shared with .Fl and many other macros)
 |happens to be doing right now.
 |
 |I have taken a note in the mandoc TODO file.  When i come round
 |to investigate more closely, chances are i will make mandoc
 |conform to what groff does in this case.

Ok, but i really wonder now -- why?  If it is normal that .Va and
other requests extend until the next macro switches the current
mode (the mdoc macros seem to transport significant amount of
state from a shallow view), regardless of punctuation, then why
should .Fn be any different?

 |>> the latter is a valid form to mark "_atexit" as a .Fn, in which case
 |>> the mdoc macros have a bug?
 |
 |> I would rather say the opposite: the comma ends the list of function
 |> parameters of `Fn'.
 |
 |Not 100% sure yet, but my first impression is that might indeed
 |be the saner choice.

I thought and think that for conformity it would make more sense
to fix .Fn than to change .Ic, .Va and all the others.
I have no idea, but for mdocmx it is the time to dig into the
macros anyway, and i'll have a look into this while doing so.
Ciao,

--steffen