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

[Steffen Nurpmeso]

Hallo Ingo, list,

Ingo Schwarze <address@hidden> wrote:
 |Steffen Nurpmeso wrote on Mon, Nov 10, 2014 at 03:21:36PM +0100:
 |> 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 difference is that for macros like .Ar, .Fl, .Ic, .Va,
 |each argument has the same semantics, so ".Ar foo bar" is
 |the same as ".Ar foo Ar bar", which makes reopening the scope
 |after punctuation vary natural.  On the other hand, .Fn has
 |positional arguments and ".Fn foo bar" is very different
 |from ".Fn foo Fn bar", so the effect observed when mandoc(1)
 |reopens the scope may seem suprising to some users.

As written: any call to another macro signals the end,
interpretation as macro can be suppressed by a \& prefix.

 |> I thought and think that for conformity it would make more sense
 |> to fix .Fn than to change .Ic, .Va and all the others.
 |
 |We are certainly not going to change the behaviour of .Ic, .Va
 |and the like, lots of existing manuals depend on that.

Ok, yes yes, it's a groff(1) mdoc(7) bug...

 |
 |> I have no idea, but for mdocmx
 |
 |What is mdocmx?

Parenthesis: it's my work-title for the mdoc(7) reference
extension (mdocmx(7)), i went for .Mx not .Ix as you've proposed
because groff(1) -ms has a .IX command (which i don't like the way
it is btw.), but no use cases for /mx/i exist; also it's the
Mdoc(7) Reference extension, which leans towards M not I, too.

I've unilaterally extended the syntax with a ".Mx -toc" command,
i hope you don't mind.  It was such a small and easy codable step
and is so nice to have for conversion to X?HTML and PDF etc.

The preprocessor that is necessary for single-pass troff(1)
implementations is completely done i guess, except for the
compatibility hack i'll add for what i think is a bug of mawk(1)
in ten minutes.  (For the list: mawk(1) requires a fflush("") in
order to "getline < NAME" a file NAME that has been written via
"print >> NAME" before, even though fflush("") is not standard and
i cannot imagine a situation where an awk(1) script would not like
to see a fflush("") on NAME before it starts a getline.)
The mdocmx(7) manual was the file that revealed that problem btw.

So after that i'm starting to dig into the macros.
Since one of the (long long term) goals of S-roff will be to add
the possibility that macros can control troff(1) in respect to
multi-pass (e.g. .troff-2pass or .troff-3pass or ".troffctl 3pass"
or whatever), in which case the mdocmx(7) extension can be solely
implemented in and by the macros themselve (just as indices and
TOC in general; safely via automatically managed temporary files,
as stated at an earlier time in another thread), that may take
a longer time to implement.  I.e., since groff_mdoc(7) is the
"upstream" it should deal with any "downstream" capabilities!
groff(1) will require the mdocmx(1) preprocessor in order to
enable users to get some value out of mdocmx(7), though.

Anyway i'll hope i can present this list a working++ patchset next
week.  (It is yet a work-in-progress on the [crawl] branch of my
S-roff repository.)  I truly think noone wants to miss the
extended referencability for at least HTML and PDF conversions
once she or he has tried it once.

 |> it is the time to dig into the macros anyway,
 |> and i'll have a look into this while doing so.
 |
 |Sure, making a good decision requires some more research,
 |which i'm not doing right now.

...if i stumble over the problem i'll open a bug report.
S-roff will ship with the fix, then :)
Ciao,

--steffen