Keith Devens .com

Fun stuff with my markup parser

I'm working out an extension syntax. From my comments in the to do list:

Add code blocks

• Maybe I'll put in code blocks as my first extension! That's a good idea!
  • My extension syntax will probably be something like this: ?!extension_name:param1=value1&param2=value2
    • How do we escape "=" and "&" within the strings? URL encoding really isn't acceptible. It should really be just \= and \&, but that makes the result a little harder to parse. It's not a simple split anymore. Actually, I guess it could be a preg_split with a "negative lookbehind assertion". Nice! Problem solved. Regexes are good.
  • So the code extension will be something like: ?!code:language=php <- this way we can have language specific highlighters even
    • An extension function will be passed a reference to the markup, plus the current location, plus any parameters automatically parsed into an array.
    • An extension function must return the location at which to pick up parsing again.
      • How does this interact with some of the flags, such as the "output_directly" flag?
      • Ok, when the function returns, if "output_directly" is on, the master parser immediately outputs all lines from the start line passed to the extension to the end line number the extension returns. This implies that an extension must not modify lines above where it starts.
        • Are there any cases where we'd want to be able to modify output above where the extension starts?
    • The nice thing is that the extension function will have access to the entire document, so it can do whatever it wants. It chooses when to end, etc.
      • But how do we keep this regular so it'll be obvious when an extension ends? Must it be "?!extension_name" (maybe "?!/extension_name"?) again? That implies that each extension knows what its own name is, but that's not a big deal
      • The alternative is to have a consistent "end_extension" flag that every extension has to adhere to.
        • The first way, we have a chance at being able to do nested extensions.
        • But the second way is more regular
        • I have to think about it.

Permalink | Comments? | id 2045

04:46 (utc-4)
edited: 23:09 (utc-4)