Re: mandocdb: use more macros

[Kristaps Dzonsons <kristaps@bsd.lv>]

On 06/12/2011 00:02, Ingo Schwarze wrote:
> Hi,
>
> here is a complete patch replacing the ones sent in late November
> in the same thread:
>
>   * use the content of 24 new macros (Ar, At, Bsx, Bx, Cm, Dv, Dx, Em,
>     Fa, Fl, Ft, Fx, Ic, Lb, Lk, Li, Ms, Mt, Nx, Ox, Sh, Ss, Sy, Tn)
>   * by removing 4 handler functions
>   * and handling 7 macros generically (An, Cd, Er, Ev, Pa, Va, Vt)
>   * introduce MDOCF_CHILD for automatic buf_appendmdoc
>   * handlers return 1 for automatic hash_put or 0 to skip it
>
> Extract more information:
>   * extract Ft and Fa from Fn
>   * Save Va and Vt completely, do not strip them
>
> Lift restrictions:
>   * use Cd, Fn, Fo, In, Va, and Vt anywhere, not only in SYNOPSIS
>   * use Ev anywhere, not only in ENVIRONMENT
>   * use Pa anywhere, not only in FILES
>   * use Er anywhere, not only in ERRORS
>   * use St anywhere, not only in STANDARDS
>   * use An anywhere, not only in AUTHORS
>
> Keep restrictions:
>   * use Nm only in NAME and SYNOPSIS
>   * use Fd only in SYNOPSIS; not touched that one for now
>
> While it's easy to split .Fn into .Ft, .Fn, and multiple .Fa's -
> the last word of the first argument is the .Fn - something similar
> will be quite tricky for .Va and .Vt.  I guess the following
> algorithm would work, but i don't want to put such complicated
> stuff into this reorg diff, so i'm going to do that later,
> in another diff:
>
>   * When .Vt is a block, treat the last word as .Vt, the rest as .Va.
>   * When .Vt is an element, treat it as just .Vt.
>   * Treat the last word of .Va as .Va, the rest as .Vt.
>
> Alternatively, maybe a bit safer:
>
>   * Always save all of .Vt as .Vt.
>   * When .Vt is a block, additionally save the last word as .Va.
>   * Always save all of .Va as .Va.
>   * When .Va has more than one word, additionally save all but the
>     last word as .Vt.
>
> Anyway, as i said, that's for a later diff.
>
> OK for this one?

Hi Ingo,

I like this, and the code has my ok.  I haven't looked it over 
carefully, but am alright with the direction.

On a different note, I'm beginning to worry a little about overloading 
the DB with dupes (int, const, char, etc.).  In short, the btree is 
growing and growing.  An option is to stuff a vector of each type/recno 
into the btree value instead of having a single pair and use R_DUP. 
I'll run some tests and see if this makes a difference: it'll reduce the 
size of the tree for sure, but popular keys might overrun the internal 
page sizes and hit performance.  I just don't know without measurements, 
but it's something to think about.

Regarding this patch... you know what I'm going to say... More docs!

Thanks,

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