[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mandoc-tech
Subject:    mandoc(3) re-write experiment time
From:       Kristaps Dzonsons <kristaps () bsd ! lv>
Date:       2012-08-15 15:28:51
Message-ID: 502BC033.5070205 () bsd ! lv
[Download RAW message or body]

Hello folks,

Enclosed is a tarball of a bare-bones mandoc(3) re-write addressing some 
long-standing issues.  DON'T PANIC!!11!!  This is just an experiment in 
design.  In short, I wanted to significantly increase roff(7) cutting 
power while redressing

  1. the illusion that roff(7) and mdoc(7)/man(7) parsing can be 
separated without severe roff(7) limitations; and

  2. the unnecessary (?) separation of mdoc(7) and man(7) ASTs, when 
man(7) could be fit into a single AST.

Some minor points are support for wchar_t, gzip'd files, recursive (and 
not reentrant) parsing, unified table routines (espie@'s ohash), and 
neatly parsed line arguments for macro handlers.

The README file lays out the file structure, general methodology, and 
implemented macros (only roff(7) right now).

If (and this is a huge, monstrous, overarching IF) this ends up being 
palatable, I'd have it produce an AST such that the front-ends could 
stay more-or-less as they are.  In other words, while I can envision a 
core re-write, the very concept of re-writing -Tascii drives me to a 
choking despair.  Somewhere in Germany, schwarze@ is filled with dread 
when I write the words "-Tascii rewrite". ;)

Anyway, over the next few weeks I'll bring in some mdoc(7) and man(7) 
support, both of which will output to a unified AST.  I'll post the 
resulting tarball here when I've done so.

Thoughts?

Best,

Kristaps

["mdocml2.tar.gz" (application/x-gzip)]
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv


[prev in list] [next in list] [prev in thread] [next in thread]