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

[Kristaps Dzonsons <kristaps@bsd.lv>]

Ingo,

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

That's the nail in the coffin to put this in libroff, as once the 
character is re-written, it can be pumped (ROFF_RERUN) back in for more 
processing.  Sigh.

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

mandoc_special() should be merged with a2roffdeco(), which would address 
this.

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

Warnings about malformed escape sequences should be raised somewhere, 
and this shouldn't be in the front-end.

Thanks,

Kristaps
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv