Allow configurability of the xexprs generated by the Markdown parse

[nxg]

Specific case first:

The Markdown library currently generates (h1 () ...) for Markdown ==== headers, and (h2 () ...) for ---- headers. For my application I'd prefer these to be (h2 () ...) and (h3 () ...) respectively. That's easy to fix, since I can just walk the tree adjusting them post-parse. However it would be neater if I could ask the parser to do that for me.

I see that this overlaps with the discussion of tree-walking, and its costs, in pull request #48, so might relate to that.

Looking at $setext-heading/para/plain in parse.rkt, I see that this h1/h2 interpretation is implemented by a (match ...) expression, so that looks like a natural location for a parameter, but you'll have a better idea than me of how expensive that would be.

There's a potential more general point, in that there are other places where it looks natural for a user to impose a different interpretation on the parse – functions $_emph and $_strong – but those cases are more marginal, and it might be that the sort of configurability I'm suggesting above is not worth generalising.

[greghendershott]

Thanks for the FR. I feel bad I've left #48 open all this time. Although I need to reload my brain with that discussion, IIRC yes I think it would address what you want to do.

I think that's probably a better way to do this, because I'm wary of accumulating more options (and the accompanying test matrices and bugs). The mission of this package is to cope with the ambiguous markdown "spec" and produce a coherent, usable xexpr. That's turned out to be remarkably difficult, at least 10x more than I imagined when I started. That's why I feel like tweaking the xexpr should be done post-parse, or, via some general user-supplied tweaker function -- because either way, it's something I'm not responsible for testing and fixing. :)

p.s. Although the === and --- headers mean heading levels 1 and 2, respectively, it's common to want to adjust them. I do that in Frog, which uses this markdown parser. I walk the xexpr post-parse. Which is the only way to do this, until I do something like #48.

[nxg]

Hmm yes: so a way of addressing this FR which appears compatible in style with the #48 possible-solution (as I understand it) might be:

(define default-interpretation-tweaker values)
(define interpretation-tweaker
  (make-parameter default-interpretation-tweaker))

; nope -- I don't like that interpretation
(define (my-interpretation element-name)
  (case element-name
    ((h1) 'h2)
    ((h2) 'h3)
    (else element-name)))
(parameterize ([interpretation-tweaker my-interpretation])
  (parse-markdown ...))

That would require the (interpretation-tweaker) function to be called here and there. possibly in a tree-walk, or possibly in strategic places when the tree is being constructed. The former option is neater conceptually, but probably inefficient if done every parse; the latter might have to be only partial, and not guarantee that it's called for every element added to the tree.

That would mean that the only thing you'd need to test would be the default case. I entirely understand your desire to keep the parser focused.

One can imagine a more general interpretation-tweaker function which gets the element content as well, but that's getting over-fancy – if I want to do that, I think I should be obliged to do it in my own time (as it were), in a post-parse walk.

Just to be clear, I think this FR is a 'nice to have' feature, but nothing stronger.