tech@mandoc.bsd.lv
 help / color / mirror / Atom feed
From: Kristaps Dzonsons <kristaps@bsd.lv>
To: Ingo Schwarze <schwarze@usta.de>
Cc: tech@mdocml.bsd.lv
Subject: Re: [PATCH] Massive restructuring into mandoc.h/libmandoc.a.
Date: Mon, 21 Mar 2011 23:34:09 +0100	[thread overview]
Message-ID: <4D87D261.300@bsd.lv> (raw)
In-Reply-To: <20110321215744.GA16603@iris.usta.de>

>> This considerably simplifies the spaghetti-mess of inclusions,
>
> Hmm, i'm looking at the details right now.
>
> I'm not sure yet, i have a suspicion this might be overdone;
> but maybe it is not.  Expect some real feedback shortly,
> hopefully tonight, or tomorrow night at the latest.

Ingo, keep me posted (I hope you don't mind my cross-posting back to 
tech@, as this includes some motivations for the recent changes).

In terms of being overdone, consider:

(1) Collapsing libmdoc, libman, and libroff into libmandoc.

I'm motivated by the wrongness of the existing approach: maintaining 
separable libmdoc, libman, and libroff compilers ignores the reality 
that Real Manuals are always mixing them.  The more we work on libroff, 
in particular, the more it's going to have to work with the underlying 
compilers.  Consider, if you will, how to handle in-line equations 
without calling into the EQN parser from libmdoc or libman (".Qq $a+b$" 
comes to mind).  This will only get worse.

(2) Collapsing main.c parsing into read.c and thus libmandoc.

The notion of "libmdoc" and "libman" as standalone parsers is a horrible 
lie.  A significant amount of parse complexity, such as pasting together 
CPP-escaped lines and validating ASCIIness, occured in main.c.  Not even 
to mention (1), and the reality that mdoc and man rarely occur on their 
own, making the roff_parsln() and mdoc/man_parse dance part of the 
document syntax itself.

(3) Collapsing mdoc.h and man.h into libmandoc.h/mandoc.h.

Two things.  First off, see (2).  The parse() functions in both of these 
headers were lies.  Second of all, and allowing for that, what do we get 
by having both mdoc.h and man.h in terms of their type definitions?  All 
this allows is for the two pairs, mdoc_XXXX.c and man_XXXX.c, to have 
their own inclusions.  Big f. deal: everybody else imports both anyway! 
  It's artificial to split them and, although this isn't OpenBSD's 
problem, it puts an unnecessary burden on distributing libmandoc.a 
(requiring mdoc.h and man.h hanger-ons) for use by other utilities.

That's pretty much all these patches accomplish.  The rest is the 
Makefile being re-written, which I've wanted to do for ages.

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

  parent reply	other threads:[~2011-03-21 22:34 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-21 17:37 Kristaps Dzonsons
2011-03-21 17:53 ` Kristaps Dzonsons
     [not found] ` <20110321215744.GA16603@iris.usta.de>
2011-03-21 22:34   ` Kristaps Dzonsons [this message]
2011-03-22  2:20     ` Ingo Schwarze
2011-03-22  9:26       ` Kristaps Dzonsons

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D87D261.300@bsd.lv \
    --to=kristaps@bsd.lv \
    --cc=schwarze@usta.de \
    --cc=tech@mdocml.bsd.lv \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).