Faramond's Tech Gripes
open main menu
a man working on some code on his laptop
Part of series: blog-meta

My Blogging Workflow

/ 6 min read

This might be a bit too early for this, as I haven’t yet settled to a stable workflow for this blog. However, let me talk about the general workflow for this blog. Afterwards, I’ll give you an overview of the three methods I am considering to adopt in making new blog entries.

General workflow

The following is the workflow I use in creating new blog entries.

  1. Create a new file inside the ‘blog project’ directory. It should be inside the src/content/blog directory. For example, this blog entry is in the src/content/blog/blog-workflow.md file.

  2. Write the blog entry in markdown. I’m already familiar with markdown as it’s widely used in social media and vanilla markdown should work just fine. However, Astro has its own flavor of markdown called MDX that extends it to do various things.

  3. Preview the content using the command

    npm run dev
    

    on the project directory root and opening the local copy of the blog on http://localhost:4321

    This allows me to preview the blog and make some changes when necessary. This is also where I would catch some errors in markdown to HTML/CSS conversion that happens via Astro.

  4. Publish the changes once I’m happy with them.

    4.1. Commit the changes via a git commit command. This only commits to the local repository, however.

    4.2. Push the changes to the remote repository via a git push command.

  5. Wait for Vercel to see the changes and deploy them. If everything goes well, the changes will be reflected on the blog site. However, if there are some errors, I might have to make some edits, and go back to step 3.

Text editors to use for making new blog entries

Now, one may use your favorite text editor to handle step 2 in the workflow above, but I’ve thought of using one of the following three editors to make new entries for this blog. In some non-specified order, they are:

  1. Zettlr and other Markdown editors
  2. Neovim
  3. VSCode/Codium
  4. Kate

Zettlr and other markdown editors

a screenshot of this blog entry being edited in zettlr There are a lot of markdown editors out there, but I have Zettlr so I’ll base this part from my experience in using it. It is built to edit markdown files. I can quickly do any formatting changes on my markdown document without much trouble among other markdown-specific features that makes it really great at editing markdown files.

However, one of the things that make this and other markdown editors unsuitable for this purpose in my opinion is I have to have the following open while doing my edits:

  • a browser for the blog preview
  • a terminal emulator for running npm run dev (for previewing) and Git commands for the publishing steps.
  • the markdown editor window

This number of open windows might be reasonable enough, but if I can reduce the number of windows open in my workflow, it’d be great. Afterall, I‌ might have other stuff open while working on the blog.

Neovim

a screenshot of this blog entry being edited in neovim

To be honest, Vi scarred me. I was made to use it back in a computer lab class in university, and even though I know how to escape it via :q!, I still am very apprehensive in using it.

However, I’ve seen the quality of life improvements made on Neovim which is a fork of Vim which is a fork of Vi. And I’m tempted to give it a try. One nifty feature of Neovim that allows me to use it for this blog is its Git integration. Without leaving the editor environment, I can run the commands to preview my changes and to commit and push once I’m happy with everything.

Despite its quality of life improvements and its rich add-on library that grows by the day, I am still apprehensive using Neovim because as with its ancestor vi, it can only take one errant keystroke to ruin everything.

Am I wrong? I sure hope so, but I wouldn’t want to be proven correct at the most inopportune moment. I included this in my list because I’ve been looking for the opportunity to finally overcome my trauma of vi and learn Neovim.

There are other more comfortable options, however.

VSCode/VSCodium

a screenshot of this blog entry being edited in vscode

Speaking of comfort, VSCode (or its non-propietary counterpart VSCodium) has been my work companion for a few years now. I’ve configured this tool to my liking, but not only does it already come with Git integration right from the start, it also has a built-in terminal emulator. All this makes it well-suited for this purpose.

In fact, this is the editor I used when first setting up this blog.

However, its power might be its own undoing. I don’t need this much power to edit markdown files, right?

Kate

A screenshot of this blog entry being edited in Kate

Now, this is something that I mostly took for granted as it came with my desktop environment, KDE Plasma. Kate (wikipedia article) can be thought of as a more powerful Notepad++ (wikipedia article). However, Kate has become more and more powerful that fell into that awkward position of being “not powerful enough for full-blown code development and yet too powerful for ordinary text editing”. This left Kate relatively unused in favor its little sister, KWrite, at least for my system.

In this case, however, it’s got just enough power for this very purpose. Again, without leaving the Kate text editing environment, I can run some commands via its built-in terminal. In addition, it has Git integration that allows me to make a git commit and a git push with just the push of two buttons (one for the commit, one for the push).

Some of Kate’s other features makes it well-suited for this purpose:

  • split window views — I can have a template, or a reference file open in one side, and on the other side, the document I’m working on.
  • sessions — I can have a set of files open (for my blog workflow, for example) saved as a session such that I don’t have to constantly open the same files whenever I would start working on the blog. This is akin to the workspace functionality I have relied on in VSCode/Codium and I’m happy to see something similar to, if not identical to it in Kate.

What I currently use

A full-desktop screenshot of this blog entry being edited in Kate, with a preview version on the browser window on the left-hand side.

In writing this very blog entry, I tried out every text editor I listed earlier with the sole exception of Neovim. I tried using Neovim-Qt, but utterly failed at it (though I suceeded while adding the screenshots to accompany this entry). I can’t even open this very markdown file. Surely I’ll learn how to do it someday.

For the time being, I think I will be sticking to Kate as it offers me the friendliest workflow with just enough power to do everything I‌ need. However, I could also open up a specialized markdown editor like Zettlr if I need some extensive formatting edits on an entry.