makedoc2 results on the other hand were nicer but that was not it either.
The structure of MD since v2 is a separation of scanner and emitter. 'scan-doc will break text into a block of [style content] pairs. 'gen-doc will take that block and turn it into something, most commonly HTML.
The features of your doc - using your ==+, ==#, etc. are in the spec of the parser. Loosely explained, the parser's rule 'resets' when it encounters a newline. It defines a few paragraph types that copies chunks of text (including 'paragraph that consumes text AND single newlines). The rest of the rule determines the paragraph style and expected paragraph type:
"===" text-line (emit sect1 text)
Could just as easily be:
"==+" paragraph (emit my-bold-paragraph para)
The way a document is presented is all in the emitter. Seems this is where you seem to be yearning for most control. My first motivation using MakeDoc was stripping it of any styles - I just wanted a minimum of HTML markup that could be embedded and properly moulded by CSS. In my script above, I iterate through the [style content] list and use 'switch to determine how to handle each, this should be sufficient for documents without any complexity. It's really then just a case of modifying the HTML that is emitted.
Example of script used in RSP (exposes [escape-html scan-doc gen-doc]):
I really should update that script though - a succinct version of make-doc though it is, it could use a bit of a refresh.
Chris: I'm trying to use oauth with Salesforce, can you help me about it? I have consumer-key and consumer-secret, but where do I set login_url? I'm trying your Etsy with Salesforce. I thought that I at least should be able to login.
I get "** User Error: Handshake Response does not contain Login URL" when I try etsy/as "username"
Is this the API you're trying to access? Looks as if it uses OAuth 2.0 (Etsy and Twitter are 1.0) - I'm not fully aware what the differences are. Note that even though Twitter and Etsy both use the same signing method (OAuth), they differ in how you get the user key - looks as if this one is different again...
They're quite different
Ok, in an effort to disentangle some of the OAuth code from specific implementations, here is an *experimental*, *largely untested* port scheme that does just that.