Markdown Demo

Commonmark should work with the usual extensions.

Headings

You can have sub-headings and more.

Sub-heading

This works too.

Inline styling

You can italic, bold, or monospace.

Block styling

Blockquotes work.

Code blocks too:

module Main where
main = print 42

Archive of inactive nodes.

No more JavaScript files at top-level, thanks to tailwind-haskell.

Modeling the structure of Banyan data, and its evolution over time. Banyan nodes form a tree structure, but are there anything else we do with it?

node’s concurrently is a decent package that mimics Procfile.

  "scripts": {
    "dev": "concurrently npm:banyan:*",
    "banyan:tailwind": "cd tailwind && make",
    "banyan:haskell": "bin/run-haskell"
  }

I use this to spawn both ghcid and tailwindcss watcher in the same process, with output interleaved. Though concurrently seems to have trouble with actually shutting down ghcid. I have to manually kill a stale ghcid spawned process to make the port available.

Keeping generated CSS in source control.

So banyan user will not have to be running Tailwind watcher. For apps like Emanote we want the user to be able to do this, though. But other Ema apps don’t need to. So there are two models here:

1. Dev-time Tailwind watcher
2. Run-time Tailwind watcher

No. 1 is simpler to implement, and should be sufficient for most Ema apps. But Emanote will need No. 2, which also brings in a long-running nodeJS process into user’s machine.

Initial prototype for this is working well. Just need to run tailwindcss watcher in separate terminal, and the model static file “versioning” trick picks up the Tailwind’s artifact, albeit with a slight delay, which is acceptable.

Banyan now uses Tailwind 3.0 to build the CSS, both in live server and during static site generation. This does add nodeJS as our dev dependencuy, but on the plus side we get all the cool new features of Tailwind (like print:hidden).

Editing and creating new nodes now happen through the VSCode extension. See [[Vkq67y0nSrC6a]] for details.

Brilliant idea. VSCode extensions are like mini-apps in themselves. VSCode exposes their ‘callbacks’ via app URIs, which can be linked to from HTML pages. I wrote a VSCode extension for Banayan that accepts two invocations:

• Edit parent
• New node (under another parent)

This takes care the rest of the Ema workflow for me – creating new nodes under an existing parent, and editing nodes. Good enough for now.

No more DOT!

Storing parent relationship in YAML now. And now I can add a CLI that creates a child node easily. Plus this is indeed easier to hand-edit than graph.dot.

VSCode supports URL handler to open files, eg: vscode://file<path> - clicking which will open that file in VSCode. This is enough to add ‘edit this node’ links in Banyon. See https://github.com/microsoft/vscode-docs/blob/main/docs/editor/command-line.md#opening-vs-code-with-urls

Shortcomings:

• It doesn’t automatically open the parent project folder
• Have to use Brave, rather than Safari, to prevent future “Open?” prompts for vscode:
  • On the plus side, this would allow Banyon to be made a ‘chrome app’

Web apps like WOC are just easy to use. How can I achieve the same for Ema apps?

Thoughts on using Banyon for actual stuff.

There are two ways to deploy Banyon sites:

• GitHub Pages (statically) … or
• run the ‘live server’ in a VPS with Syncthing doing the sync.

The latter is interesting for quick updates, but former is rather lightweight to maintain multiple sites without worrying about deployment and maintenance (not to mention security).

Decided to go with graph.dot, the DOT language, for defining all relationships. It enables multi-parent nodes, but more importantly I figured organizing wouuld easier, compared to managing the YAML meta of gazillion files.

Innovative? The static site displays the CLI to run for creating the ‘next’ note. Date is automatically injected; followed by letting the user type in the content (just as I am doing now) in the terminal. Poor man’s workflow.

File-format brainstorming

• How to represent relationships? Candidates:
  1. Filesystem hierarchy
     • Too complex to deal with
  2. YAML metadata parent in each ${node}.md
     • Adding new nodes is single-file write operation
     • Organizing nodes en masse involves fiddling with multiple files
  3. Separate file, eg: DOT, for graphs
     • Automatically allows multi-parent nodes
       • Visually, we present one parent, while demoting others.
     • Organizing nodes en masse is easier
     • Possibility to add relationship metadata

Noteworthy reports from the dev front.

Folding

The idea behind “folding”¹ is this. Over time, the stream of thoughts may grow unboundedly. In future, these streams are often a nuissance – as they would just be long lists of thought dump with no summarizing element to it. What we need here is insights, as gleaned from these streams over time. Hence, “folding” - as if a lengthy stream is “folded” to represent more permanent nuggets of information that can be consulted often.

How can Bayan facilitate this model?

• When we summarize a stream, the summary should replace the stream, while still leaving the stream in place (hidden) and linked.

Bag

A node is a “bag” if its children have no assigned data, ie., it is a “bag” of other nodes in no particular order. It does not represent a timeline, like other non-leaf nodes.

Example: [[WV0z0FUpk09RL]] is a bag.