Re: mdocml: Renamed mandoc.c to libmandoc.c.

[Ingo Schwarze <schwarze@usta.de>]

Hi Kristaps,

Kristaps Dzonsons wrote on Tue, Jul 06, 2010 at 11:24:18AM +0200:

[...]
> The fix is pretty mechanical (namely, doing it in mdoc_validate.c
> where the string pointer is reallocated on-the-fly if the escape is
> flagged), but I didn't have the energy to do it.

Hm, i shall wait and see what you are driving at, though i'm
a bit suspicious whether the parser backend it the best place
for this.

Apparently, groff supports constructs like the following,
see /usr/src/gnu/usr.bin/groff/tmac/tmac.doc:

.nr aP 3
.ds A3 Fl
.\*(A\n(aP

resolving via ".\*(A3" to ".Fl" which will be evaluated as -
the mdoc(7) flag macro.  Obfuscation, anybody?

I don't say we need to implement all that, probably most such
stuff will be rarely needed, but when we have the choice, it
is perhaps worthwhile doing some of the expansions on the
preprocessor level, maybe even iteratively.

Of course, things like special characters and font escapes,
which depend critically on the choice of the frontend, have
no business in the preprocessor, but belong into the frontend.
Yet, the escape sequence parsing logic for \*x, \*(xx, \*[xxx]
is the same for both cases.  Not sure how to organize the code
to deal with that situation, to minimize code duplication as
well as duplicate processing...

In any case, the one place where i would least expect to find
escape sequence parsing is in the mdoc/man parser backends.

[...]
>> * man.c implements man.h without explicitely including it;
>>   it is only included via libman.h

> So do all man_* and mdoc_* files (with libman.h and libmdoc.h,
> resp.). If this bothers you, it's a mechanical change.

I tend to directly include a header when i directly use symbols
defined there, even when another header i'm using implicitely
includes it anyway - but that is a matter of style and not so
important.

What i do find surprising is that a .c-file defining a function
(say, man.c defining man_parseln) does not explicitely include
the header declaring it (i.e., man.h declaring man_parseln),
but relies on another header it happens to be using (libman.h)
to implicitely include man.h.

As far as i see, that happens in two cases only:
  man.c   not including  man.h   directly
  mdoc.c  not including  mdoc.h  directly

But even that is certainly not critical.


[...]
> Ja.  I don't worry about this too much, as fixing it's
> (1) not necessary right now,

Yes, i agree there is no need to reshuffle the headers
right now.  I only looked at it because i was under the
impression you were about to start that kind of reshuffling,
and wanted to figure out how good or bad the situation
actually is, and whether one could expect perfect results
with reasonable effort.

Right now, let's not do more than simple fixes, let's not
move files around or change the basic structure, it works
well enough.


> For the record, there should ideally be a division as follows:
> 
>               +-----libmandoc----+
>            libmdoc   libman   libroff
>               |         |        |
>               +---------+--------+
>                         |
>                        main
>                         |
>             +-----------+-----------+
>             |           |           |
>           term---------html--------tree
>         ps/ascii    html/xhtml  pine/birch
> 
> It's clear that /all/ of these need the mdoc.h and man.h structures.
> Only the libmdoc/man/roff/main need the parse/access functions.

Yes, that basic picture is fine.  Except that many functions in man.h
and mdoc.h use pointers to struct man and struct mdoc, which contain
all the parser functions, so there is a bit of a looping.  But again,
no need to unwind that right now.

> Ingo, your thoughts: after the `Bk' stuff is checked in, I make
> another little tag, we clean up, fix this architectural cruft while
> it's fresh in our minds, then tag and make a real release?

Sounds good.  So i will do the main merging to OpenBSD after the
little tag, and perhaps we can then also put in two small fixes
to .Sm and .No i'm currently preparing.

Yours,
  Ingo
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv