1. Turn off night shift, then use automatic dark mode based on sunrise/sunset, or
2. Schedule night shift, and have dark mode follow its schedule.

Unfortunately, I turn on night shift all the time (a warmer screen environment, or so I tell myself — it’s mostly placebo) but prefer to only turn on dark mode after sunset, and so option 2 is out.

Here’s how I used to achieve this: for night shift, I would apply a custom schedule (such as 6:00 to 5:59) that will make sure it’s always turned on. It was then possible to manually toggle dark mode via the menu bar (by enabling the display settings to be shown, alternatively, use the control center) when using my Mac at night.

However, I recently got tired of having to do this manually. While looking through configuration options for the control center, I found the Color Filters accessibility feature and found a workaround.

First, I turn off night shift and set dark mode to be “automatic”. Hopefully — according to the docs — this will have it follow the local sunrise and sunset times (if it doesn’t work, I’ll find out soon enough).

Now for the night shift. I use the Color Tint option for the Color Filters accessibility feature (under “Display”). Then I set the tint to #FF8900 and adjust the intensity as needed.

Voila, an ad-hoc night shift that’s likely not suitable as a scientifically sound replacement, but certainly good enough for achieve the placebo effect.

Reply via email

I discovered this book through Goodreads’ annual choice awards. I’ve read and appreciated John Green’s fiction before, so I decided to give this non-fiction work of his made during the pandemic a try.

Reviewing anything and everything that humans experience as a collective isn’t a new idea. I can think of one recent example on top of my head. Neal Agawal who made the famous Password Puzzle has a game named “Earth Reviews” where topics like math gets less than three stars and cats get more than four out of five stars. Anyone can also leave a review that goes along with their rating.

Unlike Earth Reviews, The Anthropocene Reviewed includes much less general topics and explores each with much more depth, based on John Green’s personal experience. Many topics are US-specific, so it reads a lot like an autobiography that covers personal growth and development at times. Chapters are not chronologically ordered either; it can be considered a compilation of personal essays with ratings out of five stars included at the end of each chapter.

I started reading in 2023 and removed the book from my “currently reading” to my “DNF” shelf several times in the past two years. I’ve only picked it up recently for the lack of better books to read (that is, books that could fit my frighteningly precise mood at a given point in time, last year).

The reviews started off amazing. It began with reviews of topics such as humans’ temporal range, our capacity for wonder, and sunsets. It was filled with great insights and set a relaxing yet worldly scene for the stage. It gave me high hopes for what was to come.

Alas, the middle one third of the book wasn’t so interesting. It seemed as though the author was only describing personal accounts of little significance or lessons to be learned. It felt a little disconnected from the great start.

One might argue that the disconnect in the middle chapters should be blamed on my discontinuing the book after the first few chapters. But surely there should be a reason for why I felt compelled to put it off in the first place, shouldn’t there?

Luckily, I churned through the middle and finally it transitioned to a satisfying, rather existential end.

The ending was good enough that I was not only left satiated with an existential crisis, I was also reminded of how well the book began.

Overall, the reviews were insightful. I really enjoyed reading about John Green’s life in America, his travels and his perspective in things we all give little thought to each day. I’ll give it 4.5 out of 5 stars.

# Quotes

Making conclusions about a book’s quality from a 175-word review is hard work for artificial intelligences, whereas star ratings are ideal for them.

I’m reminded of something my religion professor Donald Rogan told me once: “Never predict the end of the world. You’re almost certain to be wrong, and if you’re right, no one will be around to congratulate you.”

Marveling at the perfection of that leaf, I was reminded that aesthetic beauty is as much about how and whether you look as what you see. From the quark to the supernova, the wonders do not cease. It is our attentiveness that is in short supply, our ability and willingness to do the work that awe requires.

For many species of large animals in the twenty-first century, the single most important determinant of survival is whether their existence is useful to humans.

On air-conditioning:

Like most other energy-intensive innovations, AC primarily benefits people in rich communities, while the consequences of climate change are borne disproportionately by people in impoverished communities.

A blog in the Atlantic wrote, “To think the temperature in a building is sexist is absurd.” But it’s not absurd. What’s absurd is reducing workplace productivity by using precious fossil fuels to excessively cool an office building so that men wearing ornamental jackets will feel more comfortable.

In the chapter about Staphylococcus aureus, John Green quotes an exchange between Alexander Ogston who discovered Staphylococcus and Joseph Lister who revolutionized the craft of surgery through his research into sterilization techniques:

“You have changed surgery… from being a hazardous lottery into a safe and soundly based science,” which was only a bit of an exaggeration.

After visiting Lister and observing complex knee surgeries healing without infection, Ogston returned to the hospital in Aberdeen and tore down the sign above the operating room that read, “Prepare to meet thy God.” No longer would surgery be a last-ditch, desperate effort.

On sunsets, and Indianapolis:

I don’t buy the romantic notion that scientific understanding somehow robs the universe of its beauty, but I still can’t find language to describe how breathtakingly beautiful sunsets are—not breathtakingly, actually, but breath-givingly beautiful.

Indianapolis’s favorite literary son, Kurt Vonnegut, wrote that one of the flaws in the human character “is that everybody wants to build and nobody wants to do maintenance.”

And finally, a few final quotes from the postscript.

Hank Green likes to remind me that I am made out of the materials of the universe, that I contain nothing but those materials. “Really,” he told me once, “you’re just a hunk of Earth trying to sustain a departure from chemical equilibrium.”

In a song he wrote years ago called “The Universe Is Weird,” Hank sings that the weirdest thing is that, in us, “the universe created a tool with which to know itself.”

When I think of how I have enjoyed the Anthropocene so far, I think of Robert Frost, who wrote, “Like a piece of ice on a hot stove, the poem must ride on its own melting.” So it is with poems, and so it is with us. Like ice on a hot stove, we must ride on a melting Earth, all the while knowing who is melting it. A species that has only ever found its way to more must now find its way to less.

Reply via email

So, let’s get right into it.

# Why did you start blogging in the first place?

I published my first blog post using Blogger about a decade ago as a form of public long-form note-taking for cool tech “tips and tricks” I’ve learnt every day.

Back then, I was only just getting into tinkering with technology as a hobby rather than a necessity. I realized that there were many little things I had previously ignored when it comes to the user interfaces we interact with everyday; so many opportunities for maximizing my productivity and technical knowledge that I could unlock by just paying more attention to the software and hardware I was using, and researching even just a little about them: finding out how it works under the hood, customizing and optimizing it.

I didn’t care much about how the blog looked or how posts were written. Only that I was recording my notes and publishing it for anyone who shared similar interests.

# What platform are you using to manage your blog and why did you choose it?

This blog is currently powered by Hugo, a static-site generator. I open up my terminal, make the edits, run a single command, and Hugo rebuilds my entire website from scratch. When I’m satisfied with the changes, I run another command which will deploy my website to Netlify.

I chose Hugo when starting my current blog because there were many similar blogs I liked I could reference. However, as my blog evolved I’ve started to reach the limits of what Hugo could do for me and have been experimenting with alternatives since. As of writing, I have not yet found a suitable alternative worth the switch, but I suspect this will change very soon.

# Have you blogged on other platforms before?

I’ve tried Blogger, which lets you write and publish everything within the web interface and provided you a free subdomain. Before this blog, I have also worked with Gatsby back when it was new and shiny, Django with its admin interface, Wordpress, and a couple of CMSes.

Since switching to Hugo, I have tried WriteFreely (which publishes to the Fediverse), bashblog (simple, automatically installed on tildes), smol.pub (which I still keep — it syndicates to Gemini and Gopher), and Bear Blog (which I’ve recently started trying out, and plan to keep as a secondary blog). Not to mention a whole lot of static-site generators such as Lume (which I still use for side projects), Eleventy, and most recently Astro.

# How do you write your posts?

I write drafts in Obsidian with a very minimal set up, in a vault that double-serves as my digital journal. This is useful because it allows me to write freely for myself and select from existing entries those I want to publish.

After the initial draft in Obsidian, I copy the markdown into my editor in the terminal, use Hugo’s live-reloading server to make minor edits before building and deploying to the internet.

# When do you feel most inspired to write?

Inspiration strikes when I read books, read other people’s blogs, have a long-form conversation with someone, and really any activity that makes me feel as though the ideas shared are worth recording and preserving.

There are unfortunately very few opportunities in my daily schedule to properly sit down undisturbed and write long posts in one ago. When I have a half-fledged idea, I would jot it down either in my physical notebook or on my self-hosted Memos instance to revisit later. I often begin drafting posts by writing an outline of things I want to include. This makes it easier to make context switches and jump back in when I’m able to continue the draft.

# Do you publish immediately after writing, or do you let it simmer a bit as a draft?

I usually publish immediately — bar minor edits and technical adjustments — after I’ve deemed a draft complete. However, it’s usually hard to get to this stage because I tend to edit too much while I am writing the first draft. I discovered that this is only the case when I’m typing rather than writing with a pen on paper so I’ve started to explore solutions to accommodate, such as using an unfamiliar editor or one where cognitive load is required to go back and make edits while writing.

# What’s your favorite post on your blog?

My favorite post will likely always be one that is sitting in my drafts folder — I’m passionate about the topic and I want to share it with the world, but for whatever reason, I’m unable to complete or publish it.

As for existing posts I’ve written, for now it would be The joy of feed readers and alternative ways to consume content.

# Any future plans for your blog?

Maybe a redesign, a move to another platform, or adding a new feature?

I’m constantly redesigning my blog. Moving away from Hugo is one of my priorities in my long list of website ideas. Some of which include:

• A glossary for common terms that might cause confusion throughout my blog, with links to the definitions when mentioned in blog posts. Inspired by Jeremy Friesen’s blog;
• A sitemap page,
• A page that lists books I recently read or my all-time recommendations,
• A /podroll for podcasts,
• A link garden for more permanent bookmarks within categories.

Lastly, I’ll add another question of my own.

# Why do you write? Other than your blog, do you write long-form content elsewhere?

I write to think, to relax, to make sense of my thoughts, and to communicate ideas. I think and plan a lot better when I can type away on an empty document or with a pen in my hand. I also write because I love reading books. I like to wonder about how the way words are placed makes me feel what the writer wants me to feel, see what the writer sees. Eloquence and articulacy are invigorating, and that power is contagious.

Digital journals are a great way to live more mindfully. It can also help with oversharing. I keep several digital journals around. They are accessible on all of my devices which means I can jot down ideas and reflections any time as long as I have a device with me.

I also keep several physical notebooks with different journalling purposes. I prefer notebook pages without any lines or dotted grids and a 0.7mm black ballpoint pen to write with. This way I can write free-form, include doodles alongside my writing, write sideways or in different handwriting styles of different sizes without being limited by lines and grids. Fortunately, I don’t usually have an issue with alignment and indentation or messy handwriting. Sometimes I would write with my non-dominant hand or use a different keyboard-layout when typing just so I could write slower.

# Your turn!

That’s all of the answers I will be including today. I never knew how much I could talk about my blog itself until I actually sat down and wrote it out. There are many tangents and side stories which I will save for another day, perhaps.

Now, I’d love to read your answers. I’ll be tagging Courtney, James, Joel, and Leilukin. Feel free to participate even if you aren’t tagged!

Reply via email

The circus arrives without warning. No announcements precede it. It is simply there, when yesterday it was not.

This book is one of the must-reads when it comes to magical circuses and historical fantasy. It’s rated over four stars on Goodreads with plenty of mixed reviews — the result of good marketing.

The story is set in a world with a soft magic system: “anyone can be taught” / “with a bit of studying…”

It describes a long-standing battle between two masters with different educational approaches who choose their own students and set them into duel that span over decades. Two students thrown into competition, but this time, they fell in love.

The book is full of descriptive prose that enchanted me with attractions and entertainment in the circus. There were many opportunities for sensory imagery, even when it comes to the refreshments at the small shops within the circus.

I tend to enjoy a book with long passages of beautiful prose for the magic. However, what was described just felt too intangible and inexplicable to be fully appreciated. The magical system was barely ever explained. You could argue that that was the whole point, and was what made this fantasy. But really, what does it mean for Bailey taking over the ‘weight’ of the circus in the end? What magical energy must be contained or protected and why? What happened to Celia and Marco?

In the end, the pieces of imagery that stuck with me was only the grandfather clock placed at the entrance of the circus, and the dark, sweet, swirling cups of liquid desserts sold as circus delights.

The narration follows a non-linear timeline. It explored many different characters with multiple perspectives and side plots. Many of which seemed to only provide the atmosphere with little to no contribution to the plot at all. It jumps around, lost me at times, pulled me back with flowery prose then finally threw me off again with a seemingly beautiful yet confusing ending.

Overall, I really enjoyed reading the book but the world-building just isn’t my cup of tea (pun unintentional). I give The Night Circus 3.9/5 stars; worth a re-read.

Reply via email

# General

• Launcher: Alfred
  I use Alfred only for launching applications; it’s much faster than the catch-all MacOS Spotlight Search.
• Books: Kindle Paperwhite and Goodreads (I do have a bookwyrm account if you’d like to follow my updates from the Fediverse :)
• Podcasts: Pocket Casts
• Music: InnerTune

# Productivity

• Notes: Logseq for research, Memos (self-hosted) for personal micro-blogging, and Notion for others
• Writing: Obsidian
• Todos: Todoist

Notion gives me sync with zero overhead in the free tier and its mobile apps have slightly better UX than Logseq (which is still reletively young). Logseq is an outliner, and I personally find it especially suited for certain kinds of note-taking for some of my research. I also use it for long-term personal project task management that integrates well with the journal feature.

Unfortunately, Logseq isn’t quite fit for long-form writing and drafting; so I’m currently exploring syncing options — possibly using Syncthing or Git repositories — with Obsidian.

I’ve considered using Org-mode with Emacs on the desktop and Orgzly on mobile, however Org is a little to complex for my needs (it’s true, perhaps I’m just not patient enough to overcome the learning curve) and much prefer something I can more easily manage and wrap my head around. Markdown has a wider range of support and can be converted to blog posts under my currently setup easier. If I ever decide to switch to Org for PKM, I might opt for denote or HOWM as companions.

# Internet

• Web browser: Vivaldi (graphical), w3m (textual)

  I’ve tried many graphical web browsers in the past, enough to write a long “browser reviews” post (it’s planned!)
  

  I like Vivaldi for its vertical tabs, extension customization support, built-in indicator for detected RSS/Atom feeds, and the reader mode. I disable its other features such the feed reader, calendar, notes, and mail client and would personally prefer the Firefox backend, but Vivaldi is currently the best option for personal use.

• Gemini (and Gopher) client: gelim and Lagrange

• Bookmarks: Raindrop
  I save web bookmarks in raindrop using the browser extension and mobile apps, then I export it with a script that display my public bookmarks here on my website.

• Read-it-later: Instapaper

• RSS/Atom Feed reader: yarr! (self-hosted, PWA)

• Search: DuckDuckGo for its bangs

• Email service: Proton Mail

• Email client: Proton Mail and aerc (for other emails)

# Social Media

• Reddit client: Red Reader (android)
• Mastodon client: Phanpy (PWA^[1])
• Pleroma/Akkoma client^[2]: Husky (android)
• Bluesky client: the official web client as a PWA
  I used to use TOKIMEKI, but some Bluesky features such as starter-packs prefers to open links in its official client instead, so I’ve switched away from TOKIMEKI until the situation improves.
• IRC client: senpai and gamja
• IRC bouncer: soju on SourceHut
• Matrix client: Cinny
• Lemmy client^[3]: Voyager (mobile)

# Development

Configuration and scripts of interest for everything I use in the terminal can be found in my dotfiles.

• Editor/IDE: NeoVim, Emacs (for Lisps and occasionally Org-mode)
• Terminal: Kitty
• Shell: Fish
• File manager: ranger
• Multiplexer: tmux
  I’ve tried Zellij, but I did not have a good experience with WASM plugins; perhaps I should write about it sometime.
• Dotfiles manager: yadm

That’s all of the apps I’ll include this year. I could potentially reproduce something similar on a dedicated page, only it will get out of date fairly easily. I care a lot about choosing the right tools and tailoring them to best fit my needs. Do you have similar setups? What do you like/dislike about it?

Reply via email

There are many kinds of feeds and feed readers. We’ll focus on the ones that provide the entire article from the feed, and lets you read the content directly in feed readers.

If you’ve never used a feed reader before, I highly recommend trying one out after reading this getting started guide by Matt Webb.

There’s something magical in consuming content on the internet using feed readers.

Each of us have a list of RSS/Atom feeds we follow. Feeds from friends, from internet strangers whose blog posts you serendipitously stumbled upon and decided you want more, feeds from popular publishers and newsletters and organizations and projects you want to subscribe to for updates.

Every once in a while these feeds are refreshed and you are shown a list of new entries waiting for us to read. You select one of them and the content is displayed directly within your feed reader, in a familiar and comfortable interface. Perhaps you choose to listen to them with a screen reader or perhaps you read from them directly. Either way, the content is saved in your feed reader. It’s there, together with all the other new posts waiting for you to read and all the posts from the past you have saved.

Browsing the internet is like visiting a public library without taking the books home. It’s easy to stumble upon new books and get engrossed after flipping through a few pages. As you read them, you share the physical space of all the other readers in the library. When you’re done with the book you put it back onto the shelf for the next person to pick up. The key here, is that you’re looking at something that’s provided for you to read.

Using feed readers then, is like buying physical books and having a personal library. You pick a book from the shelf. It’s yours, you can open it, hold it in your hands and read it anytime, and put it back to your shelf together with all your other collections.

It’s like subscribing to newspapers and magazines. Each day a new edition gets delivered to you. A copy for you to read on your own as you grab a cup of coffee and make yourself comfortable on your favorite couch.

With feed readers, you get your own copy. All articles look the same when you read it from your feed reader’s reading panel. Familiar and welcoming. As you read from your feed reader, you are alone with your thoughts and the author of the content in front of you. No ads, no pop ups asking you enter your email address, no floating navigation bar covering half of the screen when you choose to zoom in. Just the content^[1].

It almost feels like browsing something different from the internet entirely…

# Does this sound familiar?

It turns out, feed readers aren’t the only place you can consume content on the internet this way. Here are the few I could think of.

## Alternative browsers

How do you browse pages on the web? If you’re like most people, you might use a graphical browser such as Chrome, Firefox, or Safari.

Vivaldi, Arc, or maybe even Qutebrowser, you say? Well, all them are Chrome-based. This means websites look the same in Chrome as it does in all of those browsers^[2]. There are also other graphical browsers based on Firefox or Safari.

Apart from reading web pages rendered by browsers like these, there are other ways to browse the web. And some of them lets you consume content in a similar way to reading from feed readers.

For instance, consider text-mode browsers.

As the name suggests, web pages displayed in these kinds of browsers show only text. Images are replaced with their alt text. Only some styling rules from CSS are followed, if at all. JavaScript is usually^[3] not executed.

For the technically-inclined: I’m talking about TUI (Text User Interface) browsers such as w3m and lynx, accessed from a terminal.

Here’s how an example article looks like in such a browser. Text in blue are links, and text in green are alt text in place of images.

Like feed readers, it shows just the content. Like feed readers, the reading experience is determined by the website owner. Though unlike feed readers, you can use it to browse anything regardless of whether a website wants you to.

Textual browsers are especially fit for browsing indie blogs similar to feed readers — content-focused, and less likely to contain clutter such as graphical user interface features and popups.

There are also browsers that display mostly text, but have support for images. One example is EWW:

Images and variable-width fonts are both supported. There’s a scrollbar if you want one. Hovering on links with your mouse shows the link destination. In the screenshot, the bottom half of the screen shows a cut-off image from the article. It shows what web pages might look like with no CSS and JavaScript.

Some styles can also be rendered if there are defined inline. For example:

In this case, text within <pre> tags displayed in a monospace font. There are <span>’s within these code blocks that have set their text color using the HTML style attribute, these colors are applied accordingly.

## Read-it-later and archiving services

Services like Wallabag lets you save links to be read later. Some makes an archive of that page so that you can read them directly within the interface in case the original resource is no longer available.

This is similar to feed readers in that a local copy of an article is saved and you can freely customize how it is displayed.

## The Gemini Protocol

What’s part of the internet, but outside the World Wide Web? The web we are familiar with use the HTTP and HTTPS protocols for transferring data from a web server to your browser. Content on the web is typically served with HTML.

Gemini is a different protocol. Content on Geminispace use Gemtext, a different content format from HTML. Gemtext is similar to markdown. It is extremely simple: there are only paragraphs, lists, headings, links, quotes, and pre-formatted text. Links have to be on a line of their own. This makes parsing Gemtext easy: you only have to look at the first few characters of a line to know how to render it:

# Heading 1
## Heading 2
### Heading 3

A new line introduces a separate paragraph.

=> gemini://example.org/ This text is shown for the link
=> gemini://example.org/ Here is another link

* List item 1
* List itme 2

> Here's a quote.

There is no equivalent to CSS or JavaScript. In Gemtext, there is only content. This means it is up to Gemini “browsers” to decide how a page is shown to the user, rather than the website author — everything from the the colors and font to the margins and spacing.

Here is how a page in Geminispace looks like in Lagrange, a graphical Gemini browser.

Like feed readers, the user can customize how pages are displayed, and an author must opt-in (i.e., host their content on Gemini) for you to see it.

# Closing thoughts

Feed readers are wonderful. You can keep up with the latest updates from multiple sources without hassle, and catch up only when you want to, in a single, unified interface.

There are many ways to consume content on the internet apart from using a graphical browser with full CSS and JavaScript support. Sometimes, especially for non-textual content, it is best to use the browser that the website author wants you to use. Giving users the full control of a page’s style isn’t always a good idea. Other times, using different kinds of software to browse the web and the internet beyond the web can be a much better experience.

Do you use any of the method of browsing content on the internet I have mentioned? Do you know of any others?

Reply via email

Here’s how it worked.

I had set up a mailing list on lists.sr.ht, which allowed people to subscribe and unsubscribe using only email (no sr.ht account required).

When I published a new post, I would produce a plaintext version^[1] and post it on the mailing list as a new thread. I would then put a mailto: link with a in-reply-to field at the end of the post so that people who wish to comment can click on the link, send an email, and the content will be displayed right under the thread as a public “comment”.

The mailing list would also serve as a newsletter. Someone who was subscribed would receive new posts at their inbox. They could hit the “reply-all” button in their email client to post a public “comment”, or just “reply” to email me privately.

To display these comments at the end of each post, I could either include a link to the lists.sr.ht thread which displays all the emails in that thread nicely in a single minimalist web page, or use sr.ht’s API to fetch all replies and display them myself.

This system had many advantages:

• No JavaScript needed to fetch and display comments
• No external server required, except choosing a mailing list service.
• The authenticity of commentors were guaranteed (even more so with email encryption) since a email address to send the comment from is required.
• It double serves as a newsletter. When someone reading the post in their inbox wishes to comment, they can do so directly from their email client.
• It was simple and intuitive. We all know how to send emails.
• There was no need to sign up on my blog, or require an account on a 3rd-party service to post a comment.

Perhaps this kind of system is long tried and tested with the pitfalls discussed and explored, perhaps not. Nonetheless, I implemented it exactly as I planned, except for displaying those comments by fetching from an API — I only included a link to the corresponding lists.sr.ht thread.

Today, I am shutting down the mailing list and — following my removal of Webmentions — there will be no more comments on my blog at all. Here are are some of the reasons why I made this decision.

# 1. Posting needed more overhead

To commit to the mailing list system, I had to make sure all new posts were emailed every single time.

This means I would:

1. convert the markdown (the primary format I use for content) into plaintext by hand
2. copy the result, paste it into my email client, and write the subject line
3. send the email to the mailing list address
4. go back to my browser, navigate to the link to the thread of the email I just posted and copy it
5. go back to my editor and update the metadata of the post to include the link I copied

…before deploying my updated website.

All of these steps are non-trivial to automate, and naturally, I decided the time to figure out converting markdown into plaintext sensibly, sending emails from a script, and constructing the link of the thread, to automate the task would most definitely not be worth it over doing it manually each time.

# 2. It wasn’t really a newsletter

Sometimes I write new posts daily, sometimes once in a year. I wouldn’t subscribe to a newsletter that starts to send me emails every day following a long period of inactivity — I would use a feed reader for blogs. To support comments on all my posts I needed to send an email for every post I publish.

If I were to actually start a newsletter that mirrored content on my blog, I would do a weekly digest instead. Unfortunately, combining different posts into a single email thread doesn’t quite work for the mailing-list-as-comments system I’m aiming for here.

I didn’t consider my mailing list an actual newsletter though it could function as one, neither did I really consider it a proper mailing list — I was only using it for the sake of a platform for public comments.

# 3. It wasn’t used much

Alongside the mailto: links that lets people reply publicly to posts, I included a “reply via email privately” link. This was simply a mailto: to my personal email address with the subject line set to Re: + the title of the post. I did this for both my web and Gemini posts.

For some reason, all replies via emails I received were sent to me privately.

If I were a reader of someone else’s blog and they had a public and a private option for “reply via email”, I would also go for the private option; it’s a nice opportunity to start a personal conversation with someone. Even if I just wanted to let them know about a typo in their post, I would choose “reply via email privately” and tell them about what I liked about the post, their site, and other things that might not even be related to the post or their blog, such as a project of theirs I found useful and have questions about.

I never thought to ask those who have replied via email to my posts privately — I already appreciate the fact that they’ve resonated with ideas presented in my post and have taken the time to share their thoughts — perhaps the reasons are similar to mine, but either way, the mailing list did not see much usage.

# 4. 3rd-party content didn’t quite fit on my personal blog

I explored ways I could get replies to display at the end of a post, and I didn’t end up feeling satisfied with any way I came up with, so I ended up linking to the thread on lists.sr.ht instead.

My posts are hosted on my personal website. Everything here is authored by myself. Contents of comments, if I were to display them on posts, would be considered 3rd-party content. It would be totally fine had it been content on guestbooks, but comments at the end of my posts are not the same as guestbooks.

Blog articles also get syndicated to a number of places. To social media, to link-aggregators. My mailing list would be another place posts are syndicated to. All of these places are communities in itself, and all of these let members comment and interact with my post. Displaying comments from my mailing list on my blog would essentially declare my mailing list as the “canonical” source of comments. People from those other places might even end up commenting on the comments on my mailing list, because they are shown alongside the primary blog post content!

This just doesn’t sit right with me.

# Conclusion

I don’t regret experimenting with mailing lists for a commenting platform. I know of a few people that do something similar (but not quite identical), and I’m glad it has worked for them.

By the time you see this post, I will have removed all links to the mailing list on my blog.

You can still (and are encouraged to) use the “reply via email” link at the end of each post to share your thoughts on each topic. There is also a form that lets you send Webmentions — sites that links to my post. These will get manually included in the “syndications” section at the end of each post when there are any. You also have the option to interact from those places.

Sourcehut lists does not allow mailing list owners to view subscribers. If you had subscribed to the list, please use the RSS or Atom feeds instead, thank you for supporting me.

Reply via email

To receive Webmentions, your site needs to expose an endpoint that will collect these Webmentions in a server, and link to it in a <link rel="webmention" href="[endpoint]"> tag in your <head>. This endpoint can be self-hosted (such as webmentiond), or with a service such as webmention.io.

Someone that mentioned your site submits a POST request with a source parameter as the URL of their site, and the target parameter being the URL on your site which they linked.

You can then choose to display a list of all Webmentions of a particular page at the bottom of each page on your site, or simply get a notification and move on.

This seems simple. And it probably is if your blogging platform supports it without any overhead. But for hand-crafted personal sites with your own suite of tools — possibly statically-generated — implementing Webmentions is a bit more involved.

I set out to support Webmentions on my blog a few years ago with these goals:

• Webmentions I receive should go through manual approval before they can be displayed;
• Webmentions I receive also should have been automatically verified before being listed for manual approval (such as checking the source and target or legitimate, and that the source actually does link to the target);
• When I send Webmentions to pages I mention, the process should be automatic (such as on each deploy);
• A website should not be pinged twice for the same page on my site that mentions it;
• Display approved Webmentions so readers can continue reading further discussion (if there is any) after finishing a blog post.

In this post, I’ll walk you through the several stages of my Webmention support, revisit the list above as a checklist on each stage, and share with you my thoughts on Webmention and the eventual direction I went with Webmention support.

# 1. Receiver

I initially supported Webmentions by simply signing up on webmention.io, a free service that lets you receive Webmentions from other people. It’s made by Aaron Perecki, the author of the Webmentions specification.

In my site’s <head>, I included a link to the endpoint I was provided with from webmention.io:

<link rel="webmention" href="https://webmention.io/home.hedy.dev/webmention">

This was enough for my website to receive Webmentions, should someone choose to send them.

I could use the API at https://webmention.io/api/mentions.html?target=<page-URL> to view Webmentions for a given page on my website, and I can also automatically show a link to it at the end of each blog post on my website to save the hassle of parsing and display the entries myself.

At this stage, I did not consider sending Webmentions for other people.

• ✅ Manual approval: I could delete entries from the <webmention.io> dashboard and only include a public link that displays the list of Webmentions after all remaining entries are approved.
• ✅ Automatic verification: This was handled by <webmention.io>.
• 🟨 Automatic sending of Webmentions for changes on my site.
• ✅ A website should not be pinged twice for the same page on my site that mentions it;
• 🟨 Display approved Webmentions: well, somewhat, but not so much as I hoped for at the time.

# 2. Sending Webmentions

I decided that I should probably send some Webmentions to people, surely it takes less effort than writing a personalized email?

My site was (and still is) statically generated with Hugo. I found out about static-webmentions, the right tool for the job, and decided to give it a go.

After installing and adding the relevant configuration to my config.toml, I ran static-webmentions find.

It did not exit for several minutes, without producing any output. I noticed there was a new mentions.json file. Perhaps that was enough? I ran static-webmentions send, it crashed with a trace-back log of Goroutines.

I looked through the default configuration, added concurrentFiles = 1 and concurrentRequests = 1, and static-webmentions send worked… for some reason.

It produced a lot of output, showing me the sites it tried (and failed) to find a Webmention endpoint for. Sites that included my own and sites that aren’t even using the HTTP(S) protocol. I updated my list of excludes in config.toml and tried again.

More output.

Hang on… wouldn’t that send repeated Webmentions to sites it has previously successfully sent to?

I checked the docs again. Looks like it did support watching for new changes using an oldDir and newDir directories. Luckily, I kept a previous deployment locally. I updated config.toml, but since I hadn’t updated anything between the two runs, it would not detect any new Webmentions this (third) time around.

Well, guess I’d test it out the next time I updated my website.

# 3. Display Webmentions

As I started to share links from my site elsewhere on the internet, I decided that I should try display Webmentions.

I found out about the brid.gy service which could connect your website to social media and send you Webmentions when someone likes or comments on a post that links to your website. I had it set up, and started receiving more Webmentions.

To display Webmentions, I was initially fetching from the API provided by webmention.io. The Webmentions that brid.gy sends provided more data than simply a source and target field because they were really interactions such as likes and comments rather than simply mentioning links.

This was fine, I didn’t need to handle likes and comments from sources other than brid.gy as I was yet to receive any. I wrote HTML templates that will display all those Webmentions nicely like a comment section on a forum site.

Oops, Fediverse custom emotes were showing as full width images! I fixed those with CSS. But they didn’t have any semantic information that could differentiate them from actual images, and so all images would show as emotes…

The only solution I could think of was to edit the comment data to add a custom class="emoji". Which meant I had to save the JSON data from the webmention.io API locally. I made a script with some jq-fu to extract the relevant data, then manually merged new data with existing (edited) data manually when new Webmentions arrive every time.

This was’t too bad. An ad-hoc approval process that checks one of the receiver requirement boxes!

But even if I could get the entire process streamlined with a script, I’d still have to store the approved Webmentions somewhere if it wasn’t on webmention.io’s servers, in case I lose those files locally. It doesn’t fit to track them in Git along with my site repo, so I decided to deploy it to a temporary static site (such as pgs.sh) before each deploy.

Again, that wasn’t too bad.

A review of the third pass:

• ✅ Manual approval: I could delete entries from the webmention.io dashboard like before, but this time, the JSON data has to go through a script, from which I copy the result and manually merge it with existing Webmentions. This means I was incentived to wait for a batch of Webmentions before merging it and rebuilding my site to display the new entries.
• ✅ Automatic verification: Again, this was handled by webmention.io.
• 🟨 Automatic sending of Webmentions for changes on my site.
• ✅ A website should not be pinged twice for the same page on my site that mentions it;
• ✅ Display approved Webmentions: not so timely though, due to what I’ve described in the first checklist item.

# 4. Sender, v2

Some time later, I changed my deployment set up and a fully representative oldDir for static-webmentions was no longer possible.

Without an oldDir, it would send all Webmentions for all pages on each invocation. Not only would this be a waste of resources, it would also drastically increase the time needed for each deployment, even if I just needed to quickly update a typo.

To make matters worse, static-webmentions kept crashing even with the concurrentFiles = 1 workaround that previously worked. I had no choice but to look for alternatives.

From the IndieWeb Wiki page for Webmentions, I found a number of tools that were said to make sending Webmentions easy. Unfortunately, a good portion of them were unmaintained, and about half do not work with my setup.

I found one tool that lets you submit a link to a web page, and it handles attempting to send Webmentions for all linked sites on the page, made by none other than Aaron Parecki of webmention.io, called Telegraph.

This service made it easy to send new Webmentions when I publish new posts or create new pages — I could just submit the link of the new page. When I edit existing pages I could also submit a manual source and target and it would handle the discovery of Webmention endpoints for me.

As I started to receive Webmentions from brid.gy more frequently, I found myself using my previous setup for the receiver a lot less. I could check Webmentions easily, but fetching and processing new Webmentions just so they could be displayed at the end of each blog post was quite involved.

The reason I displayed Webmentions in the first place was for readers to have easy access to discussion and responses surrounding a blog post for further reading after finishing a post on my blog. This usually meant the Fediverse or other social media links, or link aggregators.

I decided that it wasn’t worth all the work making all the Webmentions display the way I want on my site. I could link to the specific Mastodon or link-aggregator post instead, and readers can view the interactions and comments displayed at the original source. It only added a single extra click, and it was a little weird to show 3rd party content right under my own post on a personal site.

Furthermore, despite all the controversy regarding different servers seeing a different set up of replies and different number of likes/reposts, Fediverse web clients will always be more up to date than my blog. Trying to parse brid.gy’s Webmentions and displaying it sensibly was re-inventing the wheel.

I ditched displaying Webmentions altogether and resorted to updating my site when I get notified of a new Webmention to link to that site at the end of a post.

A review of this pass:

• ✅ Manual approval: nothing is approved until I manually link to mentions on my site;
• ✅ Automatic verification;
• ✅ Automatic sending of Webmentions for changes on my site: not completely automatic, but I just need to submit the link of the new page;
• ✅ A website should not be pinged twice: Telegraph shows a list of previously sent Webmentions;
• ✅ Display approved Webmentions.

# Conclusion

If Webmentions remained what was originally envisioned — a simple source mentioning a target — things would be a lot better. This change doesn’t improve the sender situation, but it certainly makes it easier to receive and display Webmentions.

I have never tried the Webmention support on hosted blogging platforms such as Wordpress, nor have I used webmentiond (it self-hosting, as well as a mail server, which isn’t possible for many blogging hobbyists), but from my experience with implementing Webmentions on my statically generated site, receiving Webmentions is easy, sending and displaying them, not so much.

For now, I will be keeping my implementation the way I described in the fourth pass. It’s unlikely this setup will change in the foreseeable future.

My preferred method of communication is email, and I would encourage you to use the “Reply via Email” link at the end of the each post to send me your thoughts and suggestions (though there is a form to send Webmentions manually too, if you prefer). Even if you’re only notifying me of a response to my post on your site. It’s personal, it’s customized, and it’s less likely to get loss.

Reply via email

I decided to give it a try when starting a new project, the static site for Meta Ring. The many things Lume does well that made me consider the switch is beyond the scope of the article. Instead, let’s talk about one thing I miss from Hugo: shortcodes.

Note

If you’re looking for the TL;DR solution, skip to the conclusion.

The homepage for my webring required a list of webring members, which is defined in a data file as JSON. It’s trivial to use a template engine to parse the JSON and display the HTML, but I needed a way to specify where I want to insert that member list in my index.md. This would be easy had I used Hugo, because Hugo shortcodes lets me do exactly that.

For my Lume project, I explored some alternatives such as MDX, but finally arrived at a custom solution. First, I’ll explain how Hugo shortcodes work.

# Hugo shortcodes

Shortcodes in Hugo are fairly similar to components in MDX. MDX lets you write your usual JSX/TSX components and embed them directly within markdown for content pages and blog posts. This is extremely useful in CMSes and static-site generators when you need to insert a custom component of any kind directly within markdown content^[1].

In Hugo, shortcodes are defined using Go HTML templates. When executed, they receive certain metadata such as the page being rendered and the content included within the tags.

## Example

Here’s how I would implement the webring member listing in Hugo.

Create a shortcode template at layouts/shortcodes/members.html:

{{/* ...code to fetch the JSON */}}
<ul>
{{ range $members }}
  <li>
    <p><a href="{{ .url }}">{{ .name }}</a></p>
    <p><a href="{{ .colophon }}">{{ .colophon }}</a></p>
  </li>
{{ end }}
</ul>

Use the shortcode in markdown:

Some introductory material

# Members

Check out our awesome members!

{{% members %}}

---

Some content that follows.

# MDX

To implement components similar to Hugo shortcodes in my Lume site, I first looked at MDX since it was included as an official plugin.

The limitation became apparent pretty quickly. You have to define your components with JSX or TSX. If you wish to use HTML templates to define components, using them will require an ugly workaround:

<div dangerouslySetInnerHTML={
  { __html: comp.members() }
} />

Furthermore, the MDX content format also comes with its own limitations on top of both markdown and JSX, such as no support for autolinks (<url>) and no HTML/JSX comments.

And what if I decided to just roll with it and define my components in JSX/TSX? That’ll mean adding npm:react (or preact) on top of my stack of dependencies!

Which means, I’ll need something else. Preferably, something that lets me define components with HTML templates…^[2]

# Without MDX

Here’s what we currently have:

• Lume uses markdown-it by default for creating pages in markdown. It supports extension with custom plugins that change how markdown is rendered. It also supports including HTML directly in the markdown, but text within HTML tags will still be parsed as markdown, similar to GitHub Flavored Markdown.

• Lume pages have a templateEngine field. This is a list that decides how your raw .md files will get transformed into .html^[3]. By default, this will only be markdown-it. I can add vento (or another HTML templating engine) to the list, so that markdown pages can be preprocessed using a templating engine before being fed into markdown-it. This will let us use {{ templating tags }} within markdown to include our components.

• Lume has its own “generic Lume components”. You can define HTML templates, or even JSX/TSX components in the _components/ directory. Then, in page templates, use components with {{ comp.MyComponent({ ...options }) }}. The relevant component is executed and the tag replaced with the output HTML as part of the static site build process.

All this is enough to have a bare-bones implementation of Hugo shortcodes within Lume — but there’s a catch. Let me explain how to make it mostly works and we’ll get to the catch later.

# A half-baked solution

We’ll define the member list component in _components/members.html as a Lume component with Vento templating:

<ul>
{{ for item of members }}
  <li>
    <p><strong><a href="{{ item.url }}">{{ item.name }}</a></strong></p>
    <p><a href="{{ item.colophon }}">{{ item.colophon }}</a></p>
  </li>
{{ /for }}
</ul>

Note

The members variable contains the unmarshalled JSON list. This works by putting the member list in _data/members.json as Lume’s shared data.

Next, in the frontmatter of _index.md, specify that we want to use Vento (our templating engine) to preprocess the markdown before passing it to markdown-it:

title: "Meta Ring"
templateEngine: [vento, md]

And finally, in the relevant location in index.md, use the component:

## Members

{{ comp.members() }}

This works:

<h2 id="members" tabindex="-1"><a href="#members" aria-hidden="true">##</a> Members</h2>
<ul>
  <li>
    <p><strong><a href="https://home.hedy.dev/">~hedy</a></strong></p>
    <p><a href="https://home.hedy.dev/meta/">https://home.hedy.dev/meta/</a></p>
  </li>
  <!-- ... -->
</ul>

So where’s the catch?

Review the entire process:

1. index.md is rendered with Vento,
2. Vento sees a comp.members() call,
3. Vento renders _components/members.html,
4. The call is replaced with the resulting HTML,
5. Contents of index.md with comp.members() replaced with HTML <ul> ... </ul> is passed to markdown-it.

The issue here is that markdown-it continues to attempt to parse markdown even within HTML tags. But in Hugo, HTML shortcodes are strictly preserved as HTML, as-is.

If the members component were defined much less succinctly, such as including an extra newline somewhere, or if any of the item.* data we’re inserting contains newlines with markdown, these will get rendered by markdown-it.

For example:

<ul>
{{ for item of members }}
  <li><!-- look, a newline! -->

    <p><strong><a href="{{ item.url }}">{{ item.name }}</a></strong></p>
    <p><a href="{{ item.colophon }}">{{ item.colophon }}</a></p>
  </li>
{{ /for }}
</ul>

This produces:

<ul>
  <li><!-- look, a newline! -->
<p></p><p><strong><a href="https://home.hedy.dev/">~hedy</a></strong></p>
<p><a href="https://home.hedy.dev/meta/">https://home.hedy.dev/meta/</a></p><p></p>
  </li>
  <!-- ... -->
</ul>

Which means we need a way to make markdown-it ignore whatever the output of the components we use, similar to “passthrough hooks” in Goldmark for Hugo. For instance, have whatever that is between delimiters ::: be rendered as-is, like fenced code blocks^[4].

# The final solution

Unfortunately, I couldn’t find any existing passthrough plugins for markdown-it, so I rolled my own, based on the markdown-it-container plugin and the built-in fenced code block rule.

I’ve included it along with the code for the Meta Ring site in a passthrough.mjs file, and used it as a plugin in my Lume config:

import passthrough from "./passthrough.mjs";

site.hooks.addMarkdownItPlugin(passthrough, {});

Update the component template to use these delimiters:

:::
<ul>
{{ for item of members }}
  <li><!-- look, a newline! -->

    <p><strong><a href="{{ item.url }}">{{ item.name }}</a></strong></p>
    <p><a href="{{ item.colophon }}">{{ item.colophon }}</a></p>
  </li>
{{ /for }}
</ul>
:::

And that’s it! Regardless of the format of HTML we have in the component, it will be rendered as-is by markdown-it:

<h2 id="members" tabindex="-1"><a href="#members" aria-hidden="true">##</a> Members</h2>
<ul>

  <li><!-- look, a newline! -->

    <p><strong><a href="https://home.hedy.dev/">~hedy</a></strong></p>
    <p><a href="https://home.hedy.dev/meta/">https://home.hedy.dev/meta/</a></p>
  </li>
  <!-- ... -->
</ul>

# Conclusion

There isn’t yet an existing plugin for Lume that provides something similar to Hugo shortcodes, but it wasn’t hard for me to implement it myself.

Here’s how it works, in review:

• Define components in any templating engine format, in _components/. Include delimiters, or a markdown="no" attribute (specific to your markdown processor) to ensure the HTML for components are not processed as markdown. For markdown-it, I’ve implemented this functionality using a custom plugin.
• Use your templating engine to pre-process markdown pages by specifying the list templateEngine in the frontmatter. For instance, templateEngine: [vento, md].
• Include the component using the correct tags for your templating engine in markdown pages, such as {{ comp.MyComponent() }} in Vento, or <%= comp.MyComponent() %> in Eta.

And this will get you as close to Hugo shortcodes as I am aware of.

To escape tag delimiters for your templating engine in markdown, you’ll have to either avoiding setting templateEngine on pages that do not need components, or use an escape tag. For example, {{ echo }}{{ comp.example() }}{{/ echo }} in Vento produces {{ comp.example() }}.

The source code for Meta Ring is available on GitHub.

Reply via email

Pubnixes^[1] provide you a shell account and web, sometimes gemini and gopher hosting. When you log in with SSH, you are presented with a new home. A shell that may be different to your primary workstation, none of your familiar aliases and shell scripts, only some CLI programs you know and love are installed and there are some tools you’ve never heard of.

You feel a responsibility to tend to your new digital garden that is your public home page. You explore the local services, such as decentralized chat, a local forum, a wiki, and you start to discover foreign workflows you consider adopting.

Getting a package installed typically involves contacting a sysadmin. But since you are not the only user on the system, it’s likely others have similar problems and have solved it using a different tool. You get to learn new ways to do things, such as editing files and browsing the internet from the command line and the local file system. It’s like moving in to a friend’s place temporarily, or settling in a dorm room of a different country — you shop in unfamiliar places and buy things from unfamiliar brands.

It might seem daunting, especially when it’s put this way, and even more so when you look at it from the perspective of needing to set up everything again, the way you’re used to. However, similar to moving to a different country permanently, you would sometimes discover things you otherwise would not have if not for having to go out looking for alternatives.

rawtext.club (“RTC”) is a pubnix I was a member of for several years. It was recently reinstated on a different server, and I had to experience exactly what I described. Note this though: I wasn’t setting up a new laptop, it was a digital home like any other, but with different purposes. ranger, a terminal file manager I use everywhere else was not installed, and so I decided to try out another TUI file manager I’ve been looking at, broot. The fish shell isn’t installed like it used to either, so I decided to roll with bash and get familiar with ctrl-r. There were no static-site generators; I decided to try something new, such as kiln or burrow, or simply do with a hacky shell script for now until my site or gopherhole grows out of it, if ever.

On my computer, I would normally refrain from trying a different tool when I’m perfectly happy with what I have. Tools that I don’t have issues with that solve the same problem are most likely equally good when we valuate it based on how well it solves all of my problems, and usually making the migration (muscle memory and learning curve included) to make one thing a little easier isn’t worth it in the long run. On RTC, I was more than happy to try different tools because there was practically zero risk (most of my work does not occur there), and that there was no status quo to challenge in the first place.

Through this process I might discover something interesting or another way of doing things that can benefit other aspects of my digital workspace because as times goes on I would not do it the same way had I started from scratch. It’s like making different choices when you play a choose-your-adventure game a second time, or living an alternate version of myself. I see my existing decisions in new light, explore possible solutions for tools I have issues with, and most importantly, I’ve made myself comfortable in a second home quite unalike the one I’m used to.

It’s nice to start afresh sometimes.

Reply via email

I chewed over the initial idea for the former blog post (what, really, was I advocating for?) and wrote a bit more about it in detail in the webring home page — meta-ring.hedy.dev. Here are a few snippets.

Your personal home page is unique. It is the result of careful craft and deliberation and it represents a piece of you. You make intentional design choices to reflect the values you believe in and how you see yourself, how you wish to be perceived. You choose to use certain technologies that gets you excited, or makes you productive, or simply ones that just “works” for your use-case. You have built workflows and systems for and around producing content on your personal pages, systems that works just for your own little corner of the internet; and you write about all of this in a dedicated page on your very own website and share it with others like you, who are also fascinated by the cool and quirky personal web.

What should it be about?

This could be anything you want to write about which you see fit — what do you care a lot about on your personal site? Is it accessibility? Is it the fonts, the color scheme, or other aspects of design? Is it your blogging scripts, or did you hack together your own static-site generator to build your site from your own custom content format?

This webring focuses on personal websites. This means organization and project home pages will not be accepted.

It’s great to know about the technology behind your project sites, but the purpose of this webring is to encourage unique personal sites, the joy of exploration and tinkering with technology, reflecting it in your personal site, and sharing it with the world.

If you’re feeling hesitant or have questions, you’re always welcome to click on the “Reply via Email” link at the bottom of each post.

A webring is only of as much significance as its members, and this one has only just started — if you think this is something you’d like to advocate for, I’d love to see what you’ve made. Join the webring by submitting a GitHub PR, or if you prefer, patches to this mailing list for this SourceHut repo also works.

Reply via email

# Inter

The story began when I was looking for Logseq themes. I chose miA, a theme inspired by iA Writer and MacOS UI. It recommends IBM Plex Sans and iA Writer Quattro^[1] as one of the fonts for text. For some reason, neither called out to me at the time. By serendipitous discovery I found and have come to adore the Inter font. I switched to that for Logseq as well as Emacs for the Emacs variable pitch font (such as in Org Mode).

Through unrelated rabbit-holes I rediscovered the beauty of Inter in Omnivore, a bookmarking service that offers an interface for reading saved articles. I chose the Inter font yet again, and thought that this was the most beautiful thing in the world. (Perhaps the pixel-perfect display of my reading device played a bigger role to this sentiment, but Inter sure looks really good.)

# iA Writer Quattro

A year or two later, I picked up Logseq again after a period of inactivity. Logseq had gone through many rounds of updates and the miA theme was sadly no longer fully compatible. I then went back and forth between rolling my own theme (minor customizations to the default with CSS) and making the fixes on top of miA. The primary font used for text caught my attention yet again. But this time, iA Writer Quattro^[2] emerged as a new contender. Unfortunately, I quickly realized after switching to Quattro in a rush to perfect my Logseq experience, that ligatures (such as turning - followed by > into an arrow) was specific to Inter!

# IBM Plex Sans and Mono

Looking more into the iA Writer fonts I discovered that they were based on top of IBM Plex fonts. I decided to switch back to Inter for the text font, but use IBM Plex Mono for code, hoping to retain the fuzzy feeling I get when I behold the Quattro by leveraging my frequent use of code blocks, but keep those pretty ligatures^[3].

It worked out well. In fact, I was so happy with IBM Plex Mono that I jumped ship by switching to IBM Plex Mono in my terminal (where I previously always used Fira Code)!

# So… the best writing font?

I have a blog which, admittedly, receives unbearably infrequent updates until only recently. Carrying my new-found passion of admiring amazing fonts for reading and writing, I decided to try crafting a writing experience that makes the process enjoyable. In other words, incentivizing myself to write more through the lure of seeing text in a beautiful font appear before my caret. I started off with IBM Plex Sans^[4].

It worked quite well, until I started to write more frequently. Something just felt off. I missed writing prose in the terminal where my caret was block-shaped and it felt as though I was whispering into the void. Instead I was making an important speech in front of the entire world ad-hoc. What I see as I wrote was what my reader will see. It was as though I have to get everything perfect the first time or any blunders will look stupid under the beautiful variable-pitch font.

So I decided to get a free trial of iA Writer. Turns out, it uses a mostly monospace-looking font by default. How can it be? We’re not writing code! Oh, right, this came from typewriters which essentially had to produce fixed-width text. But surely there are other reasons apart from… legacy or even nostalgia? I decided to give iA Writer’s article on Duospace a proper read. A little shocked to find that “in search of the perfect writing font” — a decent subtitle for the post I am currently writing right there in the title — articulated my experience quite precisely:

In contrast to proportional fonts that communicate “this is almost done” monospace fonts suggest “this text is work in progress.” It is the more honest typographic choice for a text that is not ready to publish.

[…]

Proportional fonts save space. They suggest that you “hurry up and fill the page.” Monospaced fonts, on the other hand, feel more productive. Every typed letter translates into a homogenous visual progress in writing. It is both more relaxing to write at a slower pace and more satisfying as the progress is more tangible.

I’ve been using iA Writer Duo for drafting and digital journal ever since.

On my blog, as of writing, I use Inter for the post body, IBM Plex Sans for headings and IBM Plex Mono for code. On posts such as this one which I deem to require a more accurate representation of my writing environment, I use iA Writer Duo.

# Addendum: Reading fonts

Here are some of my favorite fonts suited for reading:

• Inter & IBM Plex Sans, as mentioned in the post
• iA Writer Duo & Quattro (the Duo might be a good choice for use in websites that goes for the “monospace”/retro vibe while remaining fairly easy to read)
• Fira Sans
• Atkinson Hyperlegible
• Basier
• Geist
• Epilogue (found on https://lume.land/)
• Aptos, the font Microsoft recently started using — to me if feels to be a blend between Inter and IBM Plex Sans, but that isn’t to say that it is superior to either.

Reply via email

# Overview

We needed syntax highlighting for code blocks in Cognate, but Hugo comes with Chroma (its syntax highlighter) baked in, and does not allow any form of customization through Hugo when it comes to supporting additional languages:

• An open GitHub issue on this topic with “Unscheduled” milestone as of writing
• No arbitrary code execution in Hugo templates
• No support for custom functions as Go plugins yet, though WASM is planned, it seems a little overkill for our purposes

Which means our only choice was to either pre-process markdown code blocks and let Hugo’s Goldmark^[1] render <pre> blocks already highlighted in markdown content files, or post-process the HTML after Goldmark is done with them.

My initial instinct was to go with the former, since finding markdown code-blocks was simply a matter of /^```cognate/ { ... } in awk. In hindsight, this was not the simpler solution, because we’ll have to keep a copy of the entire content/ directory structure for Hugo to consume, whereas processing HTML can be done per-file as Hugo is already done with it.

In reality, Goldmark ended up attempting to parse the HTML within <pre> tags as markdown (despite setting unsafe = true in the config to allow HTML in markdown). Hugo’s passthrough hooks is supposed to help with this by allowing you to configure delimiters, between which Goldmark will preserve the markdown (in our case, HTML), raw. Unfortunately this did not work for some reason.

So we opted for post-processing the HTML, and the process we ended up with looks like this:

1. Use a code block render hook to mark Cognate code blocks (e.g., language-cognate class, or a <!--cognate-->), and run Hugo as usual
2. Run a script on each output HTML file, detect Cognate code blocks (marked by Step 1)
3. Run our custom syntax highlighter, and update the HTML file

# Step 1: Render hook

The purpose of this step is for our script later on to determine which code blocks are Cognate. If you are using Chroma for other languages, you can simply look for <code class="language-[LANGUAGE]>" which is added by Chroma.

In our case, we’ll use a Hugo render hook to mark the language ourselves.

The template at layouts/_default/_markup/render-codeblock-cognate.html will executed for each Cognate code block when Hugo renders each markdown file:

{{ printf "<!--cognate-->" | safeHTML }}<pre><code>
{{ .Inner | safeHTML }}
</code></pre>

This makes the HTML output for code blocks deterministic, so we can easily look for the code we want to highlight later on.

# Step 2: Post-process HTML

In this step we use a script to update each output HTML file produced by Hugo.

Any programming language will do. Here I have opted for a simple Makefile with awk:

AWK=awk
HUGO=hugo

.PHONY: build
build:
	# ... rest of your build process
	$(HUGO)
	# ... rest of your build process
	make $(shell find public -type f -name "*.html")

public/%.html: .FORCE
	@mv $@ tmp.html
	$(AWK) -v outfile=$@ -f scripts/process-code-blocks.awk tmp.html
	@rm tmp.html

.PHONY: .FORCE
.FORCE:

In a single make/make build, it builds the site with Hugo, then runs the awk script at scripts/process-code-blocks.awk which goes through each HTML file and runs our custom syntax highlighter:

BEGIN {
  inCode = 0;
  code = "";  # The raw cognate code to highlight
  highlightCmd = "$PWD" "/scripts/highlight";
}

inCode == 0 && $0 !~ /^<!--cognate/ {
  # Print HTML other than <pre></pre> lines as-is
  print $0 >> outfile;
}

$0 == "</code></pre>" {
  # End of a code block
  if (inCode == 1) {
    printf "%s", "<pre><code>" >> outfile;
    print code | (highlightCmd " >> " outfile);
    close(highlightCmd " >> " outfile);
    printf "%s", "</code></pre>" >> outfile;

    inCode = 0;
    code = "";
  }
}

inCode == 1 {
  # Within code block
  code = code $0 "\n";
}

/^<!--cognate/ {
  # Start of code block
  inCode = 1;
}

In the script, we look for <!--cognate-->, extract the code block, run it through highlightCmd, and save it in the output file. All other lines of HTML are copied as-is.

# Step 3: The highlight script

If the language you want to use is not supported by Chroma, you might have some luck with Highlight.js or Pygments. Both allow you to implement lexers in additional languages with regex^[2].

For Cognate, we decided to go with Tree-sitter since we already have a Tree-sitter grammar for implementing editor support. Luckily, Tree-sitter CLI supports outputting highlights in HTML. So a single command will do for running syntax highlighting.

In script/highlight (highlightCmd), we’ll call tree-sitter highlight with --html/-H flag and specify the path to highlights.scm for highlight captures^[3]. It outputs a full HTML page together with line numbers implemented using a HTML table, but we only need the <pre>; sed(1) comes in handy (courtesy of @StavromulaBeta):

s/.*<table>\n\(.*\)\n<\/table>.*/\1/
s/<tr><td class=line-number>[0-9]\+<\/td><td class=line>\([^\n]*\)\n<\/td><\/tr>/\1/g

This strips out everything we don’t want from Tree-sitter’s HTML output.

Putting it together, scripts/highlight looks like this:

tree-sitter highlight \
  --query-paths $PWD/highlights.scm \
  --config-path tree-sitter.json \
  --scope source.cog -H /dev/stdin | sed -z '
s/.*<table>\n\(.*\)\n<\/table>.*/\1/
s/<tr><td class=line-number>[0-9]\+<\/td><td class=line>\([^\n]*\)\n<\/td><\/tr>/\1/g'

Two points of note:

1. --scope is needed here to have stdin be recognized as Cognate code — “source.cog” is configured in the package.json of Tree-sitter grammar repo.
2. --config-path tree-sitter.json is a config file for Tree-sitter. Conveniently, we can use this file to configure the color scheme for syntax highlighting.

Pipe in some Cognate code from stdin, and out comes rendered HTML with syntax highlighting. This script is run on each Cognate code block found in each HTML file produced by Hugo.

# Conclusion

That’s it! This is the entire build process for Cognate’s project website from start to finish with custom syntax highlighting using Tree-sitter.

Perhaps parsing Tree-sitter CLI’s output was unnecessary and using a simple regex-based syntax highlighting, or even a simple script with a Tree-sitter library in a supported programming language will make less overhead. It might also have been easier if Hugo’s passthrough render hooks worked they way I thought it would.

But well, the process I’ve illustrated above works, and it will continue to work to serve our purposes unless Tree-sitter or Hugo make drastic changes to its output format in future releases.

The source code for Cognate’s website is available on GitHub.

# See also

• Highlighting Code with Shiki in Hugo — An arguably more reliable approach to post-processing HTML by using a proper HTML parser, and Shiki for highlighting. Uses JavaScript rather than Makefiles, Awk, and Sed.
• Hugo render hooks
• Hugo passthrough hooks

Reply via email

I’ve made a webring! Read more about this topic at meta-ring.hedy.dev

If you have a personal website, chances are, you take great care into making your site yours. You update it frequently, you might have a workflow for posting on your blog. You might have made sure to properly implement features you care a lot about.

What tools do you use to draft your blog posts? Where do you syndicate your content? What are some inspirations or standards you follow for your site’s design?

I love reading personal blogs, and I also love it when people talk about their site and blog themselves. Similar to movements for /uses and /now, include a /meta page on your website and write about your website itself!

Some people include information about their site in a dedicated section of their /about, or /uses page. That’s great too — the point is to share with others how your blog is made, how it came to be, and all other meta information you want your readers to know — if you haven’t written about the topics elsewhere, a /meta page is a good place to put it. Do you link to your site’s source code in the footer? This is a good opportunity to link it in a dedicated page too.

# Examples

Seirdy has a /meta page where they talk about:

• Tools and services used to build and deploy their site
• Other versions of their site — on Tor, on Gemini
• Badges and website directories they’re part of
• Links to other pages under /meta/, such as all the things they’ve yet to implement, accessibility and design choices, etc.

Kev Quirk has a section titled “Colophon” in his about page that includes:

• His site design and inspiration
• What his site is built on and what it runs on

Gregory Hammond mentions why he writes on his blog on his about page, he also has a list of policies he follows including:

• An accessibility statement
• An AI statement
• A Privacy Policy and Terms & Conditions

icyphox has a section named “colophon” in their about page that mentions:

• The site is self-hosted
• The site is built with a custom static site generator
• Fonts used throughout their site

Jeremy Friesen has a Colophon page that details their journey in blogging with links to blog posts for each major change in the website. He even has a dedicated changelog page.

My personal website contains a /meta page that includes:

• How my site is built and where it is hosted
• Features and standards my site adopts and ones I’m yet to implement
• Where and how I write blog posts
• Website directories, webrings, and badges

Now it’s your turn! If you’ve been blogging for a while you may have come across common questions such as people asking about the tools you use to build you site, or how you host it. You can now simply link them to that page :)

# See also

• Colophons on the IndieWeb

Reply via email

Let’s explore an analogy.

Imagine a “producer” of data which inputs data in packets of size I into the system, the packets are produced unpredictably, but it is guaranteed that they come in packets of fixed size I when a new packet is produced. Then, there’s a pipe in which the input must past through to be used as output. This pipe has capacity P. (It may be helpful to visualize a physical pipe^[3] with a decently wide diameter, and incoming “packets” as blobs of liquid, or some other material of your choice.)

When P < I, we have a “bottle-neck”. Each following packet must wait for the one before to be processed in the pipe, because an entire packet cannot fit into the pipe at one time.

When P >= I, the pipe must wait for new packets to come much more often than when P < I because all incoming packets can be processed instantly as they come.

The producer here would henceforth be whichever part of my brain that produces thought, where the packets of data would be thoughts themselves — a single, standalone strand of thought that can be articulated by a word (an idea to swap an existing word with better vocabulary), a phrase, a sentence (which expresses the thought), or even paragraphs or an essay (which explains a point). You can then imagine the “pipe” or whatever the pipe is connected to on the opposite side, be the medium in which I express my thoughts — through writing on paper, through typing, through speech.

You might then draw the connection here where I theorize that P would be less than I in the case of writing (since my writing speed is relatively slower), and P is greater than or equal to I in the case of typing.

Allow me to now match my experiences with those effects I have listed for each of the conditions above about waiting/processing packets.

When writing, I often feel as though my mind is brimming with ideas on how to continue a sentence, what I can write next. All the while my hand is still focused on how the current letter should be drawn.

When typing, I can complete the process of putting down the thought currently being processed pretty quickly. Often, I’m at a loss of what to type next and have to pause.

What this means is that, writing by hand feels like many “packets” of thoughts queueing up behind a pipe too narrow in diameter just waiting to be let out. But there’s no rush. While these thoughts wait in the background, they get to “mature”. I might consider amendments to them when I finally come around to write them down.

Typing, on the other hand, makes it so all the initial “draft” versions of the thoughts are the ones materialized and I don’t get as much time mentally to chew over certain ideas before they get put on the screen. Furthermore, I would often finish typing a word or sentence then suddenly finding myself stuck, unable to determine what to type next — I lose my “train of thoughts”. My thinking can’t catch up with how quickly I’m able to type it all out. I’m often left feeling empty, no longer confident I’m able to complete the piece at all^[4].

But is being able to make adjustments to thoughts after letting them “mature” in the waiting room actually a good thing? Is it better to lower the friction between the process in my mind (thinking), and the process of writing it down? Does the increased length of breaks between the sentences typed lead to (or incentivize) longer, more focused, periods of reviewing my work? If I work on eliminating self-doubt and lack of confidence, perhaps the (increased) psychological effects caused by typing faster than I think would simply be of little significance — my hands resting on my keyboard are simply waiting for my thinking to catch up, and the analysis ends there?

I feel slow and unproductive when writing, thinking I could easily complete the task on my computer. But often I find that the written work I produce is of better quality than when I type it out. There are of course many factors that should be considered when figuring out which method of putting thoughts down works best for you; here I have only explored one aspect of the differences between typing and writing: imagining them as methods that process thoughts as they come with and the effects of the discrepancy in its “processing speed”.

Reply via email

One of the basic formatting style that can be done to plain text content would be putting blocks of lines into columns, i.e., from this:

List title 1
- Item 1
- Item 2
- Item 3

List title 2
- Item 1
- Item 2
- Item 3

To this:

List title 1  List title 2
- Item 1      - Item 1
- Item 2      - Item 2
- Item 3      - Item 3

You can easily convert the text in between those two formats just by using visual block mode to do something similar to paste(1) (see the appendix).

Here’s a video demonstration.

Creating columns

Let’s start with the vertical form, and put your cursor on the position marked by the block (▋)

List title 1
- Item 1
- Item 2
- Item 3

List title 2
- Item 1
- Item 2
▋ Item 3

Begin visual block selection mode with <C-v>. Select the first character at each line with 3k, then extend selection to the entire block using $h.

Your cursor should now be on the “2” with the entire “List title 2” and the three list items below it selected:

List title 1
- Item 1
- Item 2
- Item 3

List title ▋
- Item 1
- Item 2
- Item 3

Now hit x (or d) to remove the block and save it in one of the default registers temporarily.

List title 1
- Item 1
- Item 2
- Item 3

Now, we prepare the first list to be able to paste the second list that was just deleted. Pad spaces at the end of each line of the first list^[1]. Spaces will be shown as _ throughout the example.

If you don’t already have Vim/Neovim setup to highlight trailing spaces, you can do so temporarily now by running :match Underlined '\s\+$'.

List title 1_
- Item 1_____
- Item 2_____
- Item 3_____

Now we can paste the block we’ve deleted! Place your cursor on the trailing space after “List title 1”:

List title 1▋
- Item 1_____
- Item 2_____
- Item 3_____

And hit p:

List title 1 List title 2
- Item 1     - Item 1
- Item 2     - Item 2
- Item 3     - Item 3

Voila! The two lists are now merged into two columns side by side.

You can easily adjust the spacing between the columns using visual block mode. Place your cursor on the space in-between the two list titles:

List title 1▋List title 2
- Item 1     - Item 1
- Item 2     - Item 2
- Item 3     - Item 3

Enter visual block mode and select the entire vertical column of spaces:

List title 1▋List title 2
- Item 1    ▋- Item 1
- Item 2    ▋- Item 2
- Item 3    ▋- Item 3

Hit A to append text after each selection. Add a few spaces as you see fit, and exit visual block mode (ESC).

List title 1    List title 2
- Item 1        - Item 1
- Item 2        - Item 2
- Item 3        - Item 3

Removing columns

Let’s transform the text in reverse^[2]. We’ll break these two columns up and have them show up one following another vertically like what we’ve started with. This might be needed when the first or second list becomes too long and you decide to stop having them show up side by side.

First, place your cursor at the beginning of the third item on the second list.

List title 1    List title 2
- Item 1        - Item 1
- Item 2        - Item 2
- Item 3        ▋ Item 3

We’ll use a similar process as before to select the second list with visual block mode. Enter visual block mode with <C-v>, hit 3k, then $h.

Now delete the text like before.

Next we’ll have to create enough space under the first list for the second list to be pasted. (Note the trailing spaces here are only shown for completeness.)

List title 1____
- Item 1________
- Item 2________
- Item 3________
⏎
⏎
⏎
⏎
⏎

There should be four empty lines after a blank line following the first list.

Place your cursor on the start of the second blank line:

List title 1____
- Item 1________
- Item 2________
- Item 3________
⏎
▋
⏎
⏎
⏎

And hit p.

List title 1____
- Item 1________
- Item 2________
- Item 3________
⏎
List title 2
- Item 1
- Item 2
- Item 3

And we’re back to the original format.

You can easily remove the trailing spaces on the first list by running the substitution command on a visual selection of the first list.

Use either visual mode or visual line mode to select the first paragraph, then use :'<,'>s/\s\+$//.

List title 1
- Item 1
- Item 2
- Item 3

List title 2
- Item 1
- Item 2
- Item 3

That’s it!

Visual block mode is just one of the useful tools when formatting plain text and making ascii art. I frequently use the replace mode (“write through”) with R to overwrite content without breaking up columns.

You can learn more about the visual block mode in Vim in the docs:

:h visual-block

Appendix

Here’s an example shell session to demonstrate how you can do the same thing described in the article using the shell built-in paste(1). Again, spaces are represented as _.

$ cat > l1.txt
List title 1_
- Item 1_____
- Item 2_____
- Item 3_____
^D

$ cat > l2.txt
List title 2
- Item 1
- Item 2
- Item 3
^D

$ paste -d ' ' l1.txt l2.txt
List title 1  List title 2
- Item 1      - Item 1
- Item 2      - Item 2
- Item 3      - Item 3

As for converting it back, I might opt for awk(1), another scripting language, or just use Vim’s visual block mode.

Reply via email

Let’s start by enabling syntax highlighting in your configuration file.

In your configuration file, config.toml for example, add these settings so you can have your code highlighted and have it recognize Fenced Code Blocks for markdown:

pygmentsUseClasses = true
pygmentsCodeFences = true

Next you have to include the styles. There are two ways to go about this, one is to choose a style from the list of available styles (more on that below), and the second method is to use your own syntax theme.

You can have your own CSS styles, but there are a lot of classes, so if you’re just starting out and want to have it working quickly, you should choose an existing style.

Browse the gallery of available styles and use that style name to save the CSS file into your assets directory:

mkdir -p assets/syntax
hugo gen chromastyles --style=friendly > assets/syntax/main.css

If you’d like to use different styles for dark mode and light mode (like me), then you can change “main.css” to “light.css”, and save the dark mode style to “dark.css”. It doesn’t matter where you put the file, but just remember to use that file name with referencing it later.

You don’t have to put it under the directory “syntax” too, if you don’t want to.

# Apply the styles

You have to link to your CSS file that you’ve just created in your <head>. There are several ways you can do so.

1. Use a <link> tag and link to the URL of your CSS file, or
2. directly put the content of your file into a <style> tag.

Here’s how you can do the second method.

{{- $syntaxCSS := resources.Get "syntax/main.css" | minify -}}
<style>
	{{ $syntaxCSS.Content | safeCSS }}
</style>

Assuming your CSS file is at assets/syntax/main.css.

All set for the styling part! Now you can write some content and try it out.

Remember to include the file type when putting code in markdown.

This is not code

```sh
# and this is some sh code
echo 'hi!'
```

# Dark mode and light mode

You can have different styles of syntax highlighting for dark mode and light mode.

First you have to export or save your CSS for dark mode and light mode in separate files. Then, change the part in your <head> where you’ve included the styles:

{{- $syntaxlight := resources.Get "syntax/light.css" | minify -}}
{{- $syntaxdark := resources.Get "syntax/dark.css" | minify  -}}
<style>
	{{ $syntaxlight.Content | safeCSS }}
	@media (prefers-color-scheme: dark) {
		{{ $syntaxdark.Content | safeCSS }}
	}
</style>

This assumes you have your light styles and dark mode styles stored in assets/syntax/light.css and assets/syntax/dark.css respectively.

Instead of doing the above, you could have just put both in a single file and include the @media (prefers-color-scheme: dark) line in there directly, and this won’t require you to change your <head> at all. And of course you could have just used CSS variables and store the theme’s colors into different variables, use var(--variable-name) for each class in the styles, and finally have a different set up variable values for @media (prefers-color-scheme: dark) {}. But using the method of separating dark and light styles has the advantage of changing the themes for light or dark mode in the future with the chroma command and pipe it to the file directly, without having to edit the CSS file by hand.

# Applying syntax highlight CSS file only when it’s needed

Fetching syntax highlighting theme and putting it in your <head> means that every single page would have the syntax highlighting CSS code in the page, regardless of whether the page actually uses it. If you’d like to only include the syntax CSS files for pages that needs syntax highlighting, you can use a page parameter named something like highlight.

Here’s how it would work.

• Set a highlight param in your global config file that is set to false by default
• For each post or page in your content/ that needs syntax highlighting, include highlight: true in the frontmatter (assuming you’re using YAML).
• In <head>, check whether the page’s highlight param is set to true, and only if it’s true, the CSS resource is loaded.

In your <head>, include this before fetching the CSS resource, and put {{ end }} after </style>:

{{- if .Params.highlight -}}
<!--Put the code that fetches your syntax highlight CSS here-->
{{- end -}}

This tells hugo to only load the resource and put the CSS in <style> if the page parameter highlight is set to true.

# Read more

• Configuration options for syntax highlighting
• Highlighting specific lines in code snippets
• The built-in highlight shortcode for manual highlighting

Reply via email

I don’t know how everyone else handle different emails in .gitconfig and track dotfiles in a git repo at the same time, but here’s the solution I’ve come up with.

First, I have a global ~/.gitconfig with the default user email and some other global settings (by global I mean same cross different computers I work on).

# ~/.gitconfig
[user]
name = Default Name
email = me@default.email

Then for each machine I have a ~/.gitconfig-local file which can override some settings just for that machine, such as email, signing key, editor, etc.

# ~/.gitconfig-local
[user]
email = me@special.email

Back in the global ~/.gitconfig, I have this snippet that tells git to also look for configuration in my ~/.gitconfig-local:

# ~/.gitconfig
[include]
path = ~/.gitconfig-local

Here, I can have ~/.gitconfig tracked in my dotfiles repo, but I do not have ~/.gitconfig-local tracked. This way, I can put anything I like specific to a particular machine in the ~/.gitconfig-local, as well as SMTP settings such as password, which you wouldn’t want to end up in a public git repo.

As to setting it up on a new machine, I have a setup script in my dotfiles repo that creates an empty ~/.gitconfig-local. I use this same method with fish configs — global config and a local config, you can have a look at them in my dotfiles repo on sourcehut.

Reply via email

• Why Gemini is Not My Favorite Internet Protocol
• Gemini is Useless

As well as a few posts related to that on smol.pub:

• bentsai.smol.pub/embracing-constraints
• mieum.smol.pub/for-the-love-of-gemini

I think that those comments on Lobsters can be summarized into these main points:

• We don’t need a whole new protocol (and the corresponding new software) just because most of the web is gross
• Gemtext doesn’t have tables, text styling, images, and forms. It’s too much of a significant price having to pay just to have a simpler document-focused version of the web
• You simply can’t replace the web like this

Let’s take a look at each in detail.

# Replacing the web

[The web is] an organically grown mess of 25 years – but it will never be replaced by a dead-simple solution such as Gemini. (source)

And in response to that as mieum writes:

Almost all of these posts are obsessed with the same strawman: some supposed audacity of Gemini to attempt replacing the web. It’s hilarious that these authors (and commentors) have such poor reading comprehension.

As clearly as is written at the top on the Gemini homepage, people seem to forget that it neither wants nor tries to replace the web.

Gemini is not “the fix” for the web’s problems (or for gopher’s for that matter). It is just a habitat, really; a way to inhabit a virtual space with other people. What that is and means will always be overlooked from the point of view that assumes Gemini must be all or nothing at all; that it must be a challenger to the throne.

In my opinion, Gemini is just a virtual space to put your content and read other people’s work on. It’s not supposed to be “oh, the web sucks, let’s all just ditch the web switch over to this instead”. There are still many wonderful and peaceful things on the web. And if you’d prefer scrolling through feeds with personalized ads, or if you prefer super-responsive, sleek, modern web pages that have cute animations, then maybe Gemini might seem dull and that Gemini is not for you. Ultimately, (in the words of mieum) it’s a thriving ecosystem, and it doesn’t need to be anything more than that.

# Lack of functionality in comparison to HTML

In regards to gemtext limitations, we have to keep in mind that Gemini is a protocol. Gemtext is a markup language. You can serve whatever you like on Gemini — HTML, markdown, etc. And you can also view your HTML content over Gemini with a client that supports HTML. As far as I can tell, most features that gemtext lacks had been discussed in the mailing list before, all of which, I’m pretty sure, alternatives or workarounds were suggested. I think this comment by Alex summarises it well:

Everyone wants something added to Gemini but disagrees what that something is. Personally, I think it should be in-line images and footnotes, but if Gemini became more complex, it would lose many of the traits that make it interesting. Gemini is a technology that invites us not to try and improve or optimize it, but to accept it as it is and work around its limitations – it is intentionally austere, and this is a feature, not a bug. (source)

For me, I’m fine with not having inline images, footnotes, or maybe even syntax highlighting in preformatted text. But as to tables, yes, that could make it look better, and easier to copy contents, but it would lose its simplicity and ease of developing new software around it. If gemtext was to support a similar type of table syntax as markdown, for example, the table would look extremely broken for clients that do not support it. Unless it is put in a preformatted block, though in which case that wouldn’t solve the problem of horizontal scrolling in small screens.

In regards to inline links, sure, that could clear some clutter by removing the “[1]”, but support for this could lead to escaping characters in the syntax, and then escaping the characters that escape the characters, which adds layer upon layer of complexities, again, losing its simplicity.

For me personally, if gemtext supported tables, inline links, and maybe “—” dividers, it would make my life a tiny bit easier when creating content, (though not necessarily when developing my own client). But it’s not like you can’t do anything with gemtext. You’d just have to get used to it. Gemini strictly separates the roles of content and presentation, the author provides the content and the client can control the presentation in whatever style it likes.

# Do we need a whole new protocol?

For me personally, I like fresh starts. So sure, a new protocol, new ways to think about the internet, and some getting used to is a great idea. It might be a pain for some to set up mirrors of their web content, but it’s the experience and room to explore endless possibilities on a new medium that matters. Since you need new software, it’s a perfect opportunity to learn a new language and get your own stuff out there. It’s just the beginning, so there aren’t many “rulers” in this space, as opposed to the web with popular browsers like chrome.

At the end of the day, the fact that I create and browse content in Geminispace every now and then does not mean I’ve decided to not use the web at all, nor does it mean that all of the good content is in Geminispace instead of the web. Like mozz said on Station:

I’m not here because I hate the web, I’m here because I like Gemini. (source)

You don’t have to ditch the web to use Gemini. You get to choose what you write about, but you don’t get to choose the color of your headers, or the font size of your body paragraphs. You are free to use the web if you want that.

# Full list of references

• Why Gemini is Not My Favorite Internet Protocol (Lobste.rs)
• Gemini is Useless (Lobste.rs)
• Gemini is Useless (HN)
• bentsai.smol.pub/embracing-constraints
• mieum.smol.pub/for-the-love-of-gemini
• What is this Gemini thing anyway, and why am I excited about it? (Lobste.rs)
• mozz’s message posted on Station (via Gemini to HTTP Proxy)
• Beyond Gemini? (In response to “Why Gemini is not my favourite internet protocol”)

Reply via email

I started writing this post on 2021, February 23 but I never completed it. So in 2023 I decided to finish up this outstanding post and get it done with. Surprisingly, the content did not change much other than moving from ~team to ~cafe (more on that later). I still use Hugo and write in Markdown. And I still publish to both WWW and Gemini.

Excuse the odd placing of this post, but otherwise, enjoy the read~

This is where my gemlog/blog lives. It is statically generated with Hugo and rsync-ed to my public_html and public_gemini directories for HTML and gemini on tilde.cafe respectively on build.

The site source is always linked at the footer, pointing to the sourcehut repo though the repo is also mirrored on github.

# tilde.cafe and the Tildeverse

[The Tildeverse is] a loose association of like-minded tilde communities. Tildes are pubnixes in the spirit of tilde.club, which was created in 2014 by Paul Ford

A Pubnix is a Public Access Unix System — in other words, a unix machine on the internet that provides access to other people on the internet — which started before WWW and even the public internet. Pubnixes you may have heard of SDF, Circumlunar.Space, and tilde.club.

~cmccabe has a Pubnix History Project for you to explore if you’re interested in learning more about pubnixes.

There are a lot of pubnixes that have joined the Tildeverse since the the ~club and ~team (which hosts the tildeverse website together with many services).

Most tildes have open registerations. Users are provided around 1 GB of disk space along with SSH access and are able to host their own static site with CGI under the main tilde domain, together with services like email, gemini/gopher hosting, pastbin, and more.

However, the true value of tildes lie not in the services they provide but the people and community. The tildeverse has an official IRC network, tilde.chat, which most tildes use for their main channel of communication. They also have a radio, a mastodon instance, gitea instance, among other services. The latter two from the above are both hosted by ~ben the owner of ~team.

I chose to host my personal website on tilde.cafe, a (relatively) newer tilde that runs on Debian with a smaller user base, and for the past two years most coding projects I had done were developed on ~Cafe’s server. It’s grown to become my second digital home on the internet ever since I started to use hedy at tilde.cafe for my primary email.

It was fun to work with ~cafe admins ~spider and ~jan6 in the early days, helping to set up and write the wiki and automated website builds. We used the #cafe channel on tilde.chat for our main chat.

Some time in 2021 or 2022, jan6 is no longer able to chat with us on #cafe in tilde.chat, and since spider became busy with work and other areas of life, we needed one more admin to take care of user support on tilde.cafe. I was promoted to join spider and jan6 as sudoers and have been helping with signups and sysadmin’ing since then.

I don’t plan to move off ~cafe to host my personal website, nor email in the foreseable future. Though when I have side-projects that required dedicated servers with subdomains, I will consider using my own server and domain. Until then, I remain eternally grateful to ~cafe and other tilde-owners for maintaining awesome communities and providing welcoming spaces online for strangers to come together and build cool stuff, with money from the admin’s own pockets.

If you’re someone who is recently discovering the tildeverse I highly recommend rawtext.club (though not a “tilde” but a very cool community of extremely interesting people), ~team (they have a welcoming chat — #team — easily second most active channel on tilde.chat), ~envs (they have an Akkoma instance, used by Rohan Kumar from seirdy.one whose articles you may have come across on the internet), and of course ~cafe (drop me an email if you registered after reading this and I’ll make sure to personally approve your sign-up ;P). Others may not agree on my choices so this is not at all to downplay the worth of other tildes: there’s almost no harm in having an account on every single one, though you can definitely meet some cool people!

# Software stack & workflows

No javascript is used. All content is written in Markdown and Gemtext, with the static HTMl output generated by Hugo. The styling is done with vanilla CSS, syntax highlighting provided by chroma.

When a new blog post is written, I would ensure both markdown and gemtext sources are done, then I would run make which uses Hugo and does some miscellaneous cleaning-up to produce HTMl files at ~/public_html and gemtext at ~/public_gemini. I then use a browser to access the folder locally to check that everything is working. When something needs updating, a single make is enough to rebuild the entire site.

Finally, I commit and push. If I wasn’t working on ~cafe directly I would next log into ~cafe, pull, and make from there. It’s guaranteed to perform the same from my home computer and on ~cafe given the same Hugo versions.

Since I ran make on ~cafe, the actual ~/public_* directories will be updated on the changes would be live! 🎉

~cafe web server handles the rest. (FTR: on WWW we use nginx and on Gemini we use Gemserv.)

# Hosting

The site and gemini capsule is to be accessed at hedy.tilde.cafe; it works on both protocols. You may be curious how we could have per-user vhosts on gemini — no, there is no built-in configuration option as of writing. This is done with a shell script that appends to config file a separate server configuration when a new user sign-up is approved, written by jan6.

The <user>.tilde.cafe vhost is also supported on spartan. I wrote the spartan server that cafe uses (spsrv) and it provides a config option to use per-user vhosts.

Reply via email

hope it works!

Reply via email