Evolution of posts

I'm starting to see that there are going to be many different kinds of blog posts.

I will have files that I create and push to the repository that are just the initial nucleation sites for eventual posts that I would actually want to publish. This means I need to have a flag/mechanism for controlling publish visibility of a given file. The convention I will use for this for now is to name unpublished files .draft.md.

Actually, there are a lot of details and nuances related to files.

• I might for any reason want to move or rename a given file that contains content in it. Git is capable of tracking the movement of a file around the repo and in theory maintain this semantic history for its content. But it isn't clear if this will be perfectly tractable.
  • An example: If I create a blog post file with two sentences of an idea, and come back to it two years later:
    • First, if I am not careful git will not be able to make the connection between that initial commit and subsequently coming back to edit it. in particular editing from the initial state into authoring the post will see huge changes... suppose I change the name at this point too. only if I use git commands carefully will the chain of history be properly preserved so that I could render out the fact that the concept for this post came from the original date.
    • It's not even clear whether my intent would be consistent in terms of preserving and showing such a post as having originated from the first date. Furthermore, if I want to change this I would need to do unsavory git history-rewriting style changes to manipulate such metadata, which is highly unappealing.

In light of those considerations, the conclusion for now is that I might want a relief valve feature to let me override git based metadata with explicitly specified metadata. I may well need to establish a convention around this but for now i might be able to embed it into the name of the files. But I still haven't decided on how I would establish titles for pages. I can't just have blog post pages without titles! Cart has gone well in front of the horse here...

Many choices.

• I could use the filename as title. This means I could still add optional metadata to the filename if I establish a delimiter that terminates the title.
• I could put the title at the top. For example, I make a convention that the first # large heading becomes treated as the title. One problem with this is that it does slightly constrain my creative control over the contents of the markdown page.

Sometimes things like this could be implemented together and work together, giving more choices, and are a net win unless they start to interfere in confusing ways.

Dialects.

I also realized that I would want to at minimum be able to write markdown in two markdown dialects:

1. Markdeep (many possible links, but this one is cool)
2. Some reasonable markdown flavor that employs good code highlighting, extended with ability to insert mermaid diagrams

I am definitely still holding out hope that I can discover some simple fork out there that has been able to graft mermaid into markdeep, but in the absence of such and assuming I won't attempt to do that myself (it would be fun but a poor way to dedicate my free time) I will need to establish a way to specify which dialect of markdown I want to choose to use for a given post. One day it will bite me, but for now I am very willing to accept having to choose one or the other for a given post.

There is also a third option,

3. plain html

... so that I can build pages of arbitrary complexity.

At least this last degree of freedom can be nailed down pretty cleanly based on the file extension: .md.html files will be markdeep, .md files will be regular markdown (I'll figure out mermaid integration later...), and plain old .html will be html. It may be worth exploring shoehorning things I would normally make an HTML file for into markdown documents and see how that goes. Probably won't even encounter many issues with that, as any decent markdown renderer preserves the ability to insert html tags inside, which largely do not interfere with the markdown rendering.