Markup language is a formal language for marking up a document using text.
A popular way to differentiate markups is lightweight vs not lightweights. A classic example of the former is Markdown, which people talk too much about nowadays.
I've found a nice little tool that is perfect for post-processing HTML "dumps" (like for example exported from wikis / note taking tools or static site generators):
(I've included the GitHub link because it's quite hard to find it on the main site)
It can be used to insert snippets, mangle paths, create indices, etc.
BTW, I remember having a discussion with Lion and Timur about how HTML can be used for augmentation (in a post-processing step) instead of augmenting each and every markup language with various constructs.
A Muse document uses special, contextual markup rules to determine how to format the output result. For example, if a paragraph is indented, Muse assumes it should be quoted. Indentation is heavily used to determine if the paragraph is something different from “normal” text.
Anyway, that was then and now is now, and when I look at that code now and my current needs I feel a little unsatisfied with the needless parsing complexity of gemtext. Because even though it's very easy, it's still harder than it could be.
There are two fundamental problems with the existing document markup languages: Either they are not easy to use, or they are not well suited to write complex documents, such as technical articles, user manuals, or books. An example of “not easy to use, but suited for complex documents” would be Docbook. An example of “easy to use, but not suited for complex documents” would be Markdown.
Of course, the above categorization is simplistic. But it should serve as a good starting point to get the gist of this article which aims to delineate the kind of problems that occur in practice. You’ll see many representative examples of markup code that illustrates what’s wrong, complemented by links to more information.
You’ll also discover a new markup language. Lots of examples will demonstrate how a new syntax can lead to a language that is “easy to use and suited for complex documents”. A proof-of-concept implementation is already available.
"Xi" is a markdown-like language designed for a personal knowledge base. Color and indentation are used to highlight headings, paragraphs, links, source code examples and definitions. You can read and write Xi from within a VSCode without a need to "render" it into a "visual" web page or PDF. This makes Xi a very fast tool to keep records: you grep someting, skim through Xi pages, add or change some text from within a same editor, without a need to switch between 'edit' and 'previes' modes. An example of Xi page from my personal knowledge base with Memory color theme:
As a result of the non-standardization of blocks, our end-users suffer. If someone is using my blog engine, they can only use those blocks that I had time to implement. Those blocks may be pretty basic or incomplete. Users might want to use a fancier block that they saw in WordPress or Medium or Notion, but my editor doesn’t have it. Blocks can’t be shared or moved around very easily, and our users are limited to the features and capabilities that we had time to re-implement.
To fix this, we’re going to create a protocol called the Block Protocol.
