This is a card in Dave's Virtual Box of Cards.

Unnamed (and untamed) text format

Created: 2022-10-07 Updated: 2022-10-18

I just can’t help it. I gotta create my own text markup language (again).

I really need something that:

Can be generated super-efficiently on the fly to STDOUT
Can be parsed as easily as possible
Is designed to export to HTML first!
Has a consistent internal linking syntax (within a body of documents and when exported as a website!)

(These pain points are where AsciiDoc has specifically fallen short for me. AsciiDoc has otherwise served admirably.)

The Plan:

Design knowing that the output will be HTML
Metadata format baked in, super-simple key:value
Inline markup is freaking HARD to get right. Try to make everything line-based
I believe I helped, in tiny way, to inspire "gemtext" (circumlunar.space) in its early gestation (TODO: mailing list link here), and I’ll take inspiration back from their hard work
This format will also be used in the raw (before conversion to HTML) as a navigable format in its own right (via Vim plugin, for example) so the handling of local AND output links will be completely thought-out (TODO: link to my AsciiDoc proposal and PoC).
For output, think hard about HTML templating and how page metadata will work with it, etc. (and…though templating will be part of the HTML generator because anything else is hacky and painful, to what degree does that get bound up with this simple text format? — again, I think it’s just gonna use simple key=value metadata properties, but to what degree do I want to say "if you’re using this text format, you WILL provide the following output templating options (which will at least conditional inclusion of chunks of HTML, by the way))
A 1:1 relationship between all pages (including "index") for a dir in both raw source and output (will not abuse default document like Hugo does for "pretty urls")
Considering supporting inline <i> and <b> tags for complicated cases which will be converted to <em> and <strong> except inside code blocks.

The "this is definitely going to be converted to HTML, so make it easy to insert HTML" idea is absolutely inspired by Markdown.

I just ran across this today, which perfectly states the case:

a simple mess (idiomdrottning.org)
found via this reply (eli.li)

Sample so far (the only stuff I’m pretty sure about):

    Paragraph number one.

    Paragraph
    number two.

    ```
    block of code
    ```

    """
    blockquote
    """

    <html>
      <p>Straight inline HTML. (Everything between <html>...</html> verbatim in output!)</p>

      <a href="wow">Yup, real HTML.</a>
    </html>

TODO: Also unearth some of my Gopher posts about this to info-mine for ideas.

Sigh :-)

This’ll be at least my fourth. Previous markups:

Notegoat
Bride of Text
Bride of Text 2
tjr - "Text Junior" (github.com/ratfactor)

TODO: I have content and source code for all of these…

Why?

Is this NIH? (wikipedia.org) Sure, but experience has taught me, painfully, that if you don’t control a piece of software yourself, or if it’s not small enough for you to re-implement it yourself if you need to or it’s not part of some standard from the 1960s that you can definitely count on and there’s dozens of active implementations out there…then you’re gonna be kinda screwed at some point.

And I could do a subset and modification of AsciiDoc, but then…why? If I’m not gonna do a 100% compatible, pure implementatin, then there is truly no point in mimicking the rest of it. It’ll only be confusing. And the Markdown "flavor" situation shows us where that leads. Yuck. I don’t want to add to that.

So I’m gonna make my own thing and if it’s useful to anyone else, great. If not, great! And it’s still gonna be a super-simple plaintext format, so it can always be converted to something else later (and WAY easier than AsciiDoc or Markdown, I can promise you that!)