I’ve been writing about “Entry Points” in a Zettelkasten in March and April. Entry points are designated notes that make plunging into a topic simple. Before the section was fleshed-out, it was in a weirdly ad-hoc state I want to present to you here: it was inlined into another document.
I’ve now finished adding an example adapter to get a structural representation of a Markdown code block to my app. It bridges the abstract syntax tree (or “token tree”) of libMultiMarkdown to NSTextStorage-compatible UTF-16 substring ranges – which DeclarativeTextKit works with, reducing code size and potential for errors even further:
There’s been progress on the Declarative Text Kit API idea, and today I want to share an insight into building a DSL with Swift Result Builders. A detail that I didn’t grok until I built it. {{TOC}} Inserting text into a string, text view, or other kind of text buffer is simple enough: you need a location and then use the appropriate API to put a string into the target there.
Writing unit tests first, in the manner of test-driven development, is some kind of “wishful programming”: you create a counter-factual situation in the test code, e.g. one that uses types and methods that don’t even exist. Then you add the implementation to make the counter-factual statements (and failing tests) the actual reality.