Hi all 👋. I've started a project to try out some of the ideas I've had regarding markdown and writing. The perspective I'm coming from is that I've found it difficult to write technical articles. Especially ones containing code examples. The cut-n-paste nature of building such articles usually results in some files missing, broken code or incorrect output. I've had a bad habit of not sharing what i'm doing, so this time I want to share baby-steps i'm making with the project. It's very barebones. I've got the first feature (if you permit) working, so the below video demonstrates includable blocks.

This is great! Elements of Block Protocol and Literate Programming combined together in a new and interesting way.

Literate programming is definitely one source of inspiration! This is a form of "within-document tangling". Next is treating filenames and ID's interchangeably so that files can be included. There are some interesting graph problems in that.

Beautiful! You built something I dreamed of a few days ago. Loving the natural and terse

...

syntax for placing snippets, and the simple piggybacking onto md's image tag. Why is your code in blockquotes though instead of triple-backticks? Very interested to see how you approach file tangling. Filesystem-to-editor unidirectional inclusions will probably be easier than the other way round. Do you think bidirectional editor<>filesystem tangling would be possible at all? Maybe tracking modification timestamps?

and the simple piggybacking onto md's image tag.

There's some level of depth in this one which i'll expand upon. The original inspiration (unspiration) was that GitHub added support for a syntax like this some time ago. This was how the syntax got started. In fact, one of the goals is to be superficially markdown-compatible. I.e. headings, lists, even "NOTE" blocks should be valid both in this project and on GitHub....

Why is your code in blockquotes though instead of triple-backticks?

...but that's where the superficial compatibility with markdown ends. This project is a playground for a few ideas i've had. One of them is related fascination over languages that don't have explicit "start" and "end" tags or fences (backticks). Hence, one of my explicit goals was to get to something that won't need me to use closing tags (i'll have to write design goals down some day). It's a fun challenge! However, like you immediately noticed, using

>

is janky. The future solution to this is three-fold: • First, a block can be started by one of many characters. Blocks are generalizations of what markdown calls "lists", "headings" and "blockquotes". That means, lists are blocks (of semantic type

LIST

, and so on. • Second, supporting Markdown's "original" syntax of two-space indentation for starting a (code) block, which would make the current example almost "normal". • Third, i have something i call "sections" that are allowed on the root level. Hopefully i'll get to demo those in a few weeks.

Very interested to see how you approach file tangling. Filesystem-to-editor unidirectional inclusions will probably be easier than the other way round. Do you think bidirectional editor<>filesystem tangling would be possible at all?

I have some initial parts of this in my design, but the devil is in the details. It's one thing to support "a" editor, and another to support "any" editor. What you see on the video is an editor in the browser. I'll focus on that for now, but following filesystem events would be cool. I've approached the architecture like a build system. There's an internal graph of tasks (think: load, parse, render) that should allow for both tangling (writing out) to filesystem, as well as loading in (weaving). Loading already works somewhat, but working with graphs is tricky, and we'll see what's possible.

Maybe tracking modification timestamps?

This is definitely one key piece in there. Not sure what else, tracking syscalls?

Thank you for your thorough reply. Super excited follow your progress on this. Can you say more about why you wish to avoid explicit end markers?

Can you say more about why you wish to avoid explicit end markers

For fun mostly! But also, because I spent some time thinking too deep about what why Python chose to use indentation for scoping. There are some interesting properties, if you do "what python did" but for a markup language. For example, there can not be "too many right parentheses". This is useful, if you do collaborative editing. Consider what happens when someone writes

<div>

in a collaborative html document. All lines after it are potentially affected, until a

</div>

is added (some time later). So someone editing content at the begining of a document can break a document for someone editing the end. Using a no fences, or "line-based" or "indentation based" language alleviates some of these issues, at least in naive cases. ...But mostly for fun!