2024.03.18.

2024.03.05.

2023.12.24.

Read “Jack Baty | I won’t be joining RSS Club”

Mostly, though, it’s that blogging itself has enough problems with adoption. I’m not sure it’s a great idea to be “hiding” blog posts. Good blogs are hard enough to find these days. Why limit your writing to only those people who’ve already discovered you?

These are exactly my thoughts about this RSS Club thing. I don’t want to make my readers search for hidden content on my site (there is hidden content on my site, but it won’t be accessible by RSS), I want them to find my stuff easily.

It is already annoying that social networks, like Twitter, hide otherwise free content behind a login page; bloggers shouldn’t force readers into subscribing to something (maybe this is why I wouldn’t say I like newsletters too).

If you enjoy hiding your content, that’s fine, but we have a sparse number of good blogs these days. I want good content to be more discoverable, not hidden behind login pages and RSS feeds.

2023.12.23.

2023.12.21.

2023.12.07.

Using iA Writer as an end-to-end writing system

I’m a long-time Ulysses user, and I appreciate it since it’s a great Mac citizen, but I’m moving towards more open formats and possibly keeping more of my raw source files in Git.

I started using iA Writer a couple of months ago for my Zettelkasten writing, and having it as a backbone of my Jekyll site turned out to be great. On the other hand, I still kept my writing workflow in Ulysses, especially for long-form writings. I just wrote about how I use Ulysses projects in my writing workflow.

I wonder if having iA Writer as my only writing app is beneficial. I start to think it is, so I’ll discuss that in this post.

Keeping my writings in a Git repository

Git should be used by more people, not only by developers. It is a powerful system for keeping track of changes in a project, and it’s easy try out new ideas by creating new branches.

Git is made for text, so keeping writings in a repository is a natural workflow. For me, it’s new, though; I always used some form of library-based app for managing my writings where you can export the final product, but the raw material is usually kept in a proprietary database or file format.

iA Writer, on the other hand, uses standard text files – specifically Markdown files – and keeps them in the file system, so we can store our files in Git repositories, which can be edited directly as folders in iA Writer. I use Tower on the Mac and Working Copy on the iPad to manage all my Git repositories and to commit my changes.

The beauty of keeping my writings as simple text files is that I can work on them using multiple apps (even in Ulysses). I like the idea that I can write in iA Writer and edit my documents later in MacVim/ iVim or BBEdit. Different text editors are made for various purposes so that I can use the best one for the task. There is no one-size-fits-all.

Keeping my Markdown files simply in the filesystem, I can also capitalize on other tools like Tmux for managing Vim sessions; using it, I can even write in the Terminal (the original distraction-free writing environment) and have access to multiple panes.

Git is also an open system so I can push changes to any standard Unix-based server over SSH. Keeping my writings up-to-date between devices is not automatic but pretty straightforward to do.

Using Git for marking milestones

In Ulysses, I had this milestones-based workflow where the main writing group in the project got manually duplicated.

  • I kept groups where all sections were sheets, then duplicated these groups before significant edits and assigned version numbers for each group, like v1, v2, etc. These names had no meaning other than having a version number for the group.
  • The triggers for duplicating groups were the following:
    • Collected and sorted my Zettelkasten notes.
    • Finished the first draft.
    • Checked the grammar with Grammarly (which is just another form of editing).
    • The final version before publishing the post.

Since I can use Git directly with iA Writer, I no longer need to duplicate groups manually. I can use Git to keep the history and mark important milestones.

Keeping history in Git is pretty straightforward: I can commit my changes and have a version history on every file. I can create branches for each writing project, so my main branch only includes finished and published content. This is not that important since all of my posts are siloed into separate folders, but I still keep pull requests open for each article to comment on and see the history of changes in a nice interface.

Pull requests also mark a project’s start and end at the point of opening and merging. This is more of a psychological benefit I like to have: I feel a sense of accomplishment when I finish a project and merge it into the main branch.

Managing milestones is done through Git as well: I commit in Git that I "Published XYZ v1" or "Published XYZ v2", and then optionally, I tag these commits to mark the end of a milestone.

iA Writer can also publish my writings directly to my blog; this can be used as a marker when I reach a writing milestone. There is no need to duplicate anything locally, but I can export a manual version and keep it published as a hidden post on my blog if I want to return to a previous idea I removed.

I call these posts seedlings, and they aren’t visible in any listing, but they have a direct link, which I can use to preview how the final post will look on my blog.

I created seedlings as a tool primarily for gathering feedback from others on a document. It is my homegrown collaboration feature, which uses my site, where I’m entirely in control of my content. I can publish a hidden post, and then people can leave comments as feedback so we can collaborate without external tools.

But most of the time, I "collaborate" with myself, so I’m leaving comments on my seedlings as notes, which can be migrated back to the actual draft.

Creating pull requests for writings

GitHub pull requests are powerful tools, not just for coding but for writing, too. As I develop my writings, I can keep track of them in separate branches and associated pull requests in my Writings repository.

Pull requests allow me to annotate my text files with comments, which can serve as a built-in to-do system for my writing projects. There is a similar feature is built into Ulysses, where I can have annotations and notes on a sheet, which is one of the benefits of having a library-based app backing my raw content.

On the other hand, using open formats makes using different tools for different jobs on the same content possible. So, in this case, pull requests can be used as an annotation and journaling system around the post I’m writing. When I’m done, I can merge the PR into the main branch as I do in my software development workflow, then publish the final article on my blog.

Writing in the Terminal

Using Vim in the Terminal for writing is a new experience for me. I usually work all day in the Terminal, but I have yet to consider it a writing environment. Technically, it is the original "distraction-free writing app."

My primary text editor is Vim; next to iA Writer, I started using Tmux to keep my writing sessions open with Vim inside. It is my favorite place to do development work and works well for writing projects, too.

The beauty of plain text is immediately apparent in the Terminal. My eyes love the nice Gruvbox Dark theme, and more importantly, all of my CLI tools are just a couple of keyboard shortcuts away.

I’ve started to use my Mac more for writing-related projects lately. It is one of the most flexible environments (alongside my iPad) for managing my blog and my Zettelkasten. I spent a lot of time optimizing my Terminal environment for development, so having it available for writing is beneficial since the command line is the best place to work on any plain-text project – the two just pair really well since the UI is also text-based.

I can also jump into a running Tmux session from my iPad using Blink and continue my writing session from where I left off.

Section-based writing

In Ulysses, I used sheets for every section. I don’t have sections in iA Writer, but I can have separate Markdown files and include them as content blocks. Content blocks are not a standard Markdown feature, but they are so easy to work with that I’m fine if other apps don’t support them.

Sections are numbered and represent a sequence. When I want to create a new section, I add a unique number in the sequence. I name my sections 001.md, 002.md, 003.md etc. This workflow is similar to how Stephen Wolfram manages his notebooks in project folders: he creates a new file in the folder and starts writing.

I have a bunch of other conventions too. When I’m doing designs, I’ll typically keep my notes in files with names like Notes–01.nb or SWNotes–01.nb. It’s like my principle of not having too many file categories: I don’t tend to try to categorize different parts of the design. I just sequentially number my files, because typically it’ll be the most recent–or most recent few–that are the most relevant when I continue with a particular design. And if the files are just numbered sequentially, it’s easy to find them; one’s not trying to remember what name one happened to give to some particular direction or idea.

A long time ago I started always naming my sequential files file–01, file–02, etc. That way pretty much any sorting scheme will sort the files in sequence. And, yes, I do often get to file–10, etc. But in all these years I have yet to get even close to file–99.

I see this workflow being similar since writing projects can contain other types of assets, not just Markdown. Markdown files in iA Writer can also include code blocks, which can be stored as separate files. Think about that for a second.

Separate code snippets mean I can run these files directly in the Terminal using Ruby, Swift, or any other CLI tool. This gives me an interactive thinking space for code, like outlining, journaling, or mind-mapping. We have interactive notebooks in different environments, but I can make my writing projects similar with automation. It can be a great way to test and document code.

Let’s say I’m working on a new software project: I can have a docs folder that contains Markdown files linking to external sources in the actual code. Additionally, I can use iA Writer to embed source files as content blocks. When exporting the final version, source files are converted to Markdown code blocks in the output document.

Section-based writing also allows me to work on any part of the text at any time. This is a more natural bottom-up approach that is better than trying to fit my writing into a linear flow, where I start my post with the intro and then write the rest from top to bottom. Writing is the act of trying to fit random ideas together into a final story arc.

Using iA Writer Authorship for marking Zettelkasten notes

One of the main reasons I want to keep all my writing in iA Writer is their new Authorship feature.

It was intended to mark content pasted from other authors or generated by AI, but I want to hack around its intended purpose by marking text that was added from my Zettelkasten differently.

Since I mainly edit my Zettelkasten notes in iA Writer, using the same app as an end-to-end workflow for my final writing projects makes sense. I can switch between my notes and writings and copy and paste text into my drafts. Here’s where the Authorship feature comes into the picture. Since I can paste my Zettelkasten notes as text acquired from other sources, iA Writer would mark these paragraphs in a different style. I actually like this since edits are clearly visible over my original Zettelkasten text.

I have a global Authorship setup in my iA Writer settings, where my Zettelkasten is marked as "Other." This feature was intended for text copied from text-related AI apps, but if you think about it, my Zettelkasten is a "thinking partner," according to Luhmann, so in that sense, marking it as authored by "Other" sources makes sense.

Zettelkasten provides a system that, much like GTD, outlines the necessary physical steps for learning about something, generates new ideas from that knowledge, and links concepts to write a cohesive long-form text.

Creating a story is like developing a skeleton. We will add our precise thoughts on top of this skeleton. These thoughts can come from our heads, or if we use an active note-taking system, our notes can serve as a basis for them.

When we use these notes, we still have to form them in a way that makes sense in the context of the current story. The Authorship feature lets me highlight the differences between a piece of text that is just a source of a draft and the actual text I edited.

Since most of my articles contain notes developed in my Zettelkasten, I want to see these differences. Visually getting a difference between the original note and the edited version makes sense. It lets me visualize the differences between texts from other sources or texts I’m actively writing.

Using iA Writer as an end-to-end writing app

As I mentioned, I’m editing my Zettelkasten in iA Writer. I’m also editing my writings in iA Writer. How about including AI in the same app as well?

I developed a tool a few months ago called RubyGPT, a Ruby gem that lets me use ChatGPT in the Terminal. I also integrated it into iA Writer using Apple Script so I can have an ongoing ChatGPT chat session saved into a Markdown file. These chat sessions are stored in my ~/Documents/Chats folder, which is also added to my iA Writer library. Sadly, this tool only works in macOS, although I can export ChatGPT chat sessions from Drafts, too, where I’m using this action to have a similar workflow.

All my writing-related plain text lives inside iA Writer, so I consider the app an end-to-end tool for all my writing needs. In theory, I can do this with Ulysses, too, which can also work on external files, but iA Writer doesn’t hide the Markdown syntax, so I can see the original text as John Gruber intended.

With the Authorship feature, I can also see the changes I made to externally generated text, regardless of whether it’s coming from an AI source or my Zettelkasten. I still have to do the work and edit this text into a proper post.

I love this integrated workflow of starting with reading, having highlights processed into notes, getting these notes under control, and then using them as the building blocks of my posts. This workflow lets me naturally develop ideas and use them in places where they make sense.

No need to force anything.

I can write about whatever I feel like at the moment.

2023.12.04.

Read “How I Take and Publish Notes – Jim Nielsen’s Blog”

Jim writing about his reading note publishing process:

I like to let my notes sit for a couple days (or even weeks). I find that if I come back to a note and still find it interesting/insightful that means it’s worth keeping, so I put in the work of cleaning it up and publishing it.

I don’t do this. If I see something interesting, I usually publish it immediately (like this post). On the other hand, I have a Zettelkasten site, which contains more in-depth notes that are also coming from reading notes. However, that site is so new that I haven’t really published anything that counts as reading notes there yet.

2023.11.01.

Apple and journaling

Jason has concerns about the format of Apple Journal:

Like Apple Notes, the Journal app works without the Files app. Instead of your journal entries being discreet text files or similar that can be managed in the file system, they’re built into the app itself. It might work, like Apple Notes, using a SQLite database within the Journal app container.

I’m also moving into using more open formats for journaling, although I think there is a slight difference between a journal and a diary.

  • Keeping a journal in general is a mindfulness practice for keeping track of what I’m doing throughout the day.
  • Keeping a diary is more personal on the other hand. It helps us to write about our feelings and nice or bad things that happened to us.
    • This is the reason why I like to have the On This Day notification from Everlog in the morning.

Both of these practices provide a clearer picture, bringing us closer to the state of the past than just a simple memory.

Our memories give a false image because we can only remember the good things. This distorts the past and overvalues things that were not as good as we remember.

We can’t trust our memories, but we can trust a diary/journal, since it acts as a bookmark to the past, showing what happened in our lives. It functions as a backward tickler file, bringing things from the past to us. This retrieved information helps us to better understand ourselves in the future. We can see the difference between the past and our current state clearly, which can provide a new perspective on how we handle a current situation.

In essence: both of these practices allow us to compare our present self with our past one and draw conclusions.

So back to Apple Journal…

The only thing I see myself using Apple Journal for is the missing “add a description to multiple photos” app for now.

Sometimes I want to have a short description of an event that is stored in Photos, and since both apps are from Apple, hopefully, the integration will be better than duplicating my photos into yet another app as attachments.

Otherwise, I don’t see myself migrating away from Everlog in the foreseeable future.

2023.10.23.

Append-only storage and developing ideas

There are multiple ways to develop ideas. Sometimes the best one is where you can’t change the history of an idea. It’s there as breadcrumbs to go back in time and see how an idea was developed.


Other people use email as an append-only note-taking tool and storage medium. From How I use append-only log to store information:

Choose any email client you like and basically dump all your PDFs, notes, digitized papers, files into it as it arrives from various sources. Just write a meaningful subject that you can search for later. You can use labels or folders to organize, but mostly just send it to an email address of your choice and archive it. Usually, you will not even read it again after you have saved it.

The E-mail format itself is well understood and has many features. The max attachment size of most service providers is around 20 MB. It’s more than enough. Try to use plain text for just taking short notes and messages to yourself. If you want to dump more than 20mb of files, just archive it or split into many emails or upload it to cloud storage and copy and paste the link to email.

When you need the information. It’s there. Always.

No more fiddling with the file managers, renaming. It is saved as it is.

Even if you would like to edit, you can just forward the message again to yourself with the edit and delete the original one.

You can also use it to schedule mails and track future tasks, TV shows, anime, movies or Reminder to yourself in the future. If you are working on a piece of text for a long time, you can just keep it as a draft and keep working. It will be auto-saved.

I am a fan of the bullet journal method. Handwritten text is immutable. The same goes for emails. Once you send it, it becomes immutable.

I don’t know if other use emails to store all their digital content in emails like me. But it’s a pretty neat trick.


Here’s how Steve Jobs used email to write his Stanford commencement speech:

In January 2005, John Hennessy, the president of Stanford, asked Steve to give the commencement address to that spring’s graduating class. Steve agreed.

On and off for the next six months, Steve took stabs at writing his talk. He emailed stories and memories to himself. He asked friends, Apple colleagues, and the screenwriter Aaron Sorkin for their thoughts. In the end, however, he wrote the speech on his own. Even three days before the event, Steve was unsatisfied with his talk. He sent it to a friend, warning, “I’ll send it to you, but please don’t puke. I never do stuff like this.” He was still refining the speech the morning that he gave it. Uncharacteristically, Steve read from the lectern, rather than memorizing his text (as he did with Apple keynotes) or speaking extemporaneously from a few scrawled notes (as he did in nearly every other talk).

Steve was happy with the speech—he emailed himself a copy a few days after giving it—but he generally deflected the praise that he received for it. “I bought it on CommencementSpeeches.com,” he joked to one person. The commencement address has been viewed millions of times online and is included[…]


These use cases are similar to how I use email threads to develop ideas in the GTD capture phase, where I’m leaving notes for myself within an email thread. All I have to do is send a reply to my own address by replying to an email, so Apple Mail keeps the message in the same thread.

One of the benefits of using this method is that I can still see the email as part of the thread, but my notes will be kept private.

This is helpful for various purposes, such as making code review comments or jotting down ideas by replying to email notifications but changing the recipient to my own address, which acts a bit like the poor men’s version of HEY’s sticky notes

I also have another app where I keep journal entries called Everlog. I’m thinking about applying the same append-only storage idea there and never editing my Everlog entries after I added them. It is also an append-only app, where entries shouldn’t be changed afterward, only deleted. I can always add a follow-up to an entry but I should never change it, so I can see how something was developed over time.

This is why I like to use Drafts for capturing and drafting ideas. I can easily edit them while I’m working on the idea, but I shouldn’t change them too much after I share them with their destination app (except when I continue working on them).


Related posts

Zettelkasten Note

2023.05.21.

Get A Notebook And Write Stuff Down

Greg Morris writing about notebooks:

You don’t need to start a second brain, or do some weird PKM stuff, you just need to have a place full of things that will help you out. Record things you find interesting, things you need to remember, things that might help you work later on, literally anything you might need later on. You don’t need to start a commonplace book or anything, you just require a notebook around, all the time.

I start to wonder if there is a more straightforward way to manage ideas other than keeping a full PKM or Zettelkasten.

2023.03.23.

My Notebook System – ratfactor

This year is going to see my journal/log’s 10th anniversary and 100th notebook.

I read the whole article and took a lot of notes which inspired me to think about how I can consolidate my capture (logging) habit a bit more into one place, but still keep multiple capture tools.

After finishing this essay, it feels like Dave accidentally invented GTD for himself in a different form based on a stream of captured ideas that are moved up in the chain to have projects and next actions.

The part at the end where he writes about weekly, monthly, and yearly recaps feels very GTD-esque.

I actually tracked my time in a notebook like this before. I had a timestamp of when I started and when I ended a session of work. I have a long history of working in sessions, as I used to do a lot of freelance work, which requires time tracking (a session means that I focus on one task for a more extended period of time). My only question is how Dave transcribes his notebook entries into his digital system? I did it by hand, and it was awful.

Anyway, this is an excellent write-up of a fantastic system that I’m going to use as inspiration.

2023.03.22.

Ultra-mobile writing environments

So one thing I consider a compelling use case for a big iPhone and a small iPad mini is using them as a mobile writing environment. I could easily publish an essay from my iPhone or iPad mini just by thumb-typing. I want to explore this use case in more detail in the future.

We have had people doing this for years now, watch and read the following stuff from Patrick Rhone or Yuvi Zalkow.

I have a MacBook Pro and iPad Pro to write, so why am I interested in this phenomenon? I like when people think outside the box regarding their device usage.

The iPhone and the iPad mini are considered content consumption devices by almost everyone, which I’m afraid I have to disagree with. I create all kinds of things using these devices. I take photos, write notes and blogposts, sometimes create/edit Shortcuts, and SSH into remote servers to fix issues. Heck, I even edited an entire podcast episode on my iPhone using Ferrite while I was sitting on the train. It was actually quite fun to do. Being an owner of a big phone like the iPhone 14 Pro Max, I’m even expecting myself to use it more to create rather than consume.

Thumb-typing lengthy notes and blog posts on these devices maybe seems to be an ineffective way to write. Still, there is a focused environment to be found here—especially if you set up iOS to send only essential notifications—so even a smartphone can be a device that makes you focused.


I’m not going into details on notifications here, but let me just tell you, it’s not your smartphone that makes you distracted. It’s your laziness to set up notifications properly that makes you distracted.

2023.02.16.

2022.01.31.

I collected my reading notes and highlights from “Digital Zettelkasten: Principles, Methods, & Examples” by David Kadavy.


daunting projects to compete with little dopamine hits

How can I increase the dopamine hit of completing a project?

When you have a digital Zettelkasten, there’s a third option: do small things with small notes, straight from your phone.

When we have a small amount of time, we can do small things with our notes, even on our phone.

A lot of small steps can take us very far.

Yet instead of these tiny actions adding up to essentially nothing, they feed your curiosity in a productive way and drive your projects forward.

GTD takes us closer to our goals with small steps.

We have to set up small next actions when we are tired, so we can do a lot of small things which gives us some form of baseline success.

Instead of using my brain power to try to remember things, I’m using it to write better articles, newsletters, and books. I finally found a bicycle for my mind.

We have to use the brain for doing creative stuff, not remembering things.

Yes, we should rethink educational curricula centered around memorization, but looking things up is at some point a waste of working memory. That’s brain power that could be used to think creatively, rather than to try to grasp a bunch of facts just retrieved.

Instead of looking up information that we have to understand, we can use the energy of the brain for creative things.

Sometimes ignorance is more comfortable than learning, because learning means we have to go through the work of changing.

Learning is harder than ignoring facts.

It’s not so easy it’s boring, and it’s not so hard it’s a slog.

We can create new permanent notes with Craft inline of another note, which can be extracted out into a new note.

Some examples of fleeting notes, from my own Zettelkasten:

Uses of fleeting notes:

  • highlights from books
  • highlights from articles, blog posts
  • our ideas

Yes, Henry Ford’s assembly line went quickly by eliminating waste, but the cars had to be designed first – a process that wasn’t so easy to speed up.

It’s easier to automate a system than invent it. That’s a long and hard process.

As you read, make fleeting notes.

Once you’ve exported your highlights, review them and highlight, once again, the parts of those highlights that are the most interesting.

Look at the highlights of your highlights and re-write the interesting ones in your own words.

I’m taking notes as I read, I don’t rewrite them afterward.

Associative thinking promotes a positive mood, so it shouldn’t be a surprise how fun this task is.

It feels good when we find a connection between two Zettelkasten notes.

Now take only the most interesting ideas from the literature notes, and turn each into individual permanent notes.

Next, I have a link back to the literature note from which I wrote this permanent note. That looks like this:

We can link permanent notes from literature notes, so we can see in backlinks where it’s coming from.

If you try this process and it feels boring to you, it may be because the material you’re reviewing doesn’t feel relevant, doesn’t interest you

It is a warning sign if we are bored while writing our Zettelkasten. It means that we don’t care about the topic, or we know it well already.

The main con of Folgezettel is it’s unnecessary in a digital Zettelkasten. Folgezettel is most advantageous in a paper-based Zettelkasten, because it allows you to easily arrange paper based upon how a sequence of notes follow one another.

Having a series of notes (or outline of notes) can be helpful in a digital Zettelkasten too because we are forced to stop and think about where a new note should fit in the outline.

create keywords based upon patterns you see, which inform theories you’re working on.

Having an index is the same as having “Table of Contents” notes.

2021.12.21.

2021.04.13.

Posting status updates from Craft

I’m tinkering with Craft, using it as a daily running journal. The outline-like logging format grouped by dates feels natural because I can write things out without much organization. The freeform nature of Craft makes this process relatively quick and easy.

It just occurred to me that I could also publish posts started as a block in my journal. I started writing this post’s idea, then turned it into a subpage inline and fleshed out more; finally, it was published via Ulysses.

Having this freeform block-level editing in Craft makes it an all-in-one tool for drafting out ideas into whatever I want.

2021.02.23.

HEY for World

HEY for World can be an excellent idea for those who don’t want to be bothered to set up a blog.

When I write a certain kind of email — aka a blog post — why do I have to address it to someone? Why can’t I just address my thoughts to the world? Direct to the web for anyone and everyone? Rather than define the recipients, I just write and let the recipients find me.

Although we had this before and it failed miserably.

2020.02.24.

Using Zettelkasten to draft our writings

Connected notes in a Zettelkasten can be used as a draft of unformed manuscripts. (The importance of connecting notes in a Zettelkasten)

The writing process starts when we create our notes using the physical routine of the Zettelkasten method. We’re proactively making drafts by connecting our notes, so instead of writing everything from scratch, we can collect related notes together and edit them to form a more coherent basis for a manuscript. In practice, we’re trying to find order in our notes, because from the Zettelkasten’s perspective, each note can relate to another one from any direction.

This whole workflow is the result of the Zettelkasten letting things naturally emerge.