Org Super Agenda

Org-super-agenda really helps wrangle the agenda view when there are lots of tasks.

My config is so far pretty simple…

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

(use-package org-super-agenda
  :ensure t
  :config
 (setq org-super-agenda-groups '((:name "Today"
				:time-grid t
				:scheduled today)
			   (:name "Due today"
				:deadline today)
			   (:name "Important"
				:priority "A")
			   (:name "Overdue"
				:deadline past)
			   (:name "Due soon"
				:deadline future)
			   (:name "Waiting"
			       :todo "WAIT"))))

Here’s a sample of what it looks like…

How my editor looks is important to me

This post at irreal laments the fact that people make such a big deal out of how their text editor looks, suggesting that it’s only the functionality that matters.

He quotes Vivak Halder…

“why should you ever care how your editor looks, unless you’re trying to win a screenshot competition?”

In general, I agree. What my editor can do and how it does it is what’s most important.

But there’s an easy answer to Vivak’s question: I care about how my editor looks because I stare at it all day. How could I not care deeply about how it looks?

There are many great reasons to defend Emacs, but appearance isn’t one of them. Dismissing aesthetics as unnecessary feels like defensive rationalization.

I’ve spent many hours trying to improve the look and feel of my Emacs experience, and I’ve gotten it to the point where, while no one would call it beautiful, it’s at least no longer aesthetically offensive.

I want the things I use and stare at all day to be pleasant. Emacs doesn’t need to be beautiful, but it does need to be nice.

Now, if I could only find a decent font and a light theme I don’t hate1.

  1. Please don’t say “Leuven”. I would try and make my own theme but I doubt I could come up with anything I like, even if I was capable of making one. [return]

Sticking with Dropbox

It’s fashionable lately to “ditch” Dropbox for other sync services. The reasons stated are usually around cost or privacy. This is understandable, but for anyone with a significant number of files and/or services using Dropbox, the time and complexity of switching could easily be costlier than what it would be to just continue using Dropbox.

Dropbox has only rarely caused me grief, and only with resource usage. Sometimes the client takes too many of them. Otherwise, it’s been reliable and dependable for many years.

I’ve used Syncthing and Resilio Sync as alternatives. Both are fine, but other services depending on sync don’t often support them, meaning I still need to use Dropbox for some of my “stuff”. This puts me in the unhappy situation of keeping things in 2 places. I did this for a while, and it ended up a confusing mess.

iCloud is handy, but only on my Macs and iOS devices. It’s also never been as dependable as Dropbox. I’ve lost things. And stories like iCloud data loss with macos and ios 13 betas doesn’t help my confidence.

I use Dropbox on Linux and I once fumblefingered a command and deleted a bunch of files. These were easily restored using Dropbox. I like the way Dropbox works today.

As much as I love to try new things, I don’t feel that my file storage and sync system would benefit from the sort of tinkering that be would required to change it.

I’m bucking the trend and sticking with Dropbox.

Wrangling Hugo's RSS templates

I just lost an hour “fixing” Hugo’s handling of RSS feeds.

Hugo’s default rss template only includes each post’s .Summary, but I want to include the full .Content. There is no configuration setting for this, so in order to include full post content I have to override the entire template. This seems nuts to me, but whatever. I had already done this a while ago and it’s worked fine…until I updated Hugo to v0.55.0.

Hugo’s 0.55.0 release introduced (what I consider) a breaking change which caused the RSS feed to include all posts. The rssLimit configuration setting was replaced by a [services.rss] which relies on Config.Services.RSS.Limit. I wish someone would’ve told me. To be fair, there is something about this in the release notes but it’s not obvious and doesn’t call anything out as a breaking change, so I missed it.

I dutifully changed my settings to match, but it didn’t fix the problem. Of course it didn’t, because I’d overridden the default template and my version had no idea about Config.Services.RSS.Limit. The default RSS template is internal to Hugo but is shown in the documentation. I copied it over my own template, re-did my change to .Summary but still no luck. My RSS feed was still showing all posts. Turns out the version in the docs was wrong. Instead, I poked around the code and found the actual source for the default RSS template and copied that to ./layouts/index.rss.xml. Finally, I was again seeing full content and only the first 20 posts in the feed.

The problem then was that the feed contained entries for other non-post files that I’d edited. I only want posts in the feed, so I had to make an additional change to the template. The default is…

1

{{- $pages := Data.Pages -}}

I changed mine to…

1

{- $pages := (where .Data.Pages "Type" "post") -}}

Here’s my final version of the template.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

{{- $pages := (where .Data.Pages "Type" "post") -}}
{{- $limit := .Site.Config.Services.RSS.Limit -}}
{{- if ge $limit 1 -}}
{{- $pages = $pages | first $limit -}}
{{- end -}}
{{ printf "<?xml version=\"1.0\" encoding=\"utf-8\" standalone=\"yes\" ?>" | safeHTML }}
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>{{ if eq  .Title  .Site.Title }}{{ .Site.Title }}{{ else }}{{ with .Title }}{{.}} on {{ end }}{{ .Site.Title }}{{ end }}</title>
    <link>{{ .Permalink }}</link>
    <description>Recent content {{ if ne  .Title  .Site.Title }}{{ with .Title }}in {{.}} {{ end }}{{ end }}on {{ .Site.Title }}</description>
    <generator>Hugo -- gohugo.io</generator>{{ with .Site.LanguageCode }}
    <language>{{.}}</language>{{end}}{{ with .Site.Author.email }}
    <managingEditor>{{.}}{{ with $.Site.Author.name }} ({{.}}){{end}}</managingEditor>{{end}}{{ with .Site.Author.email }}
    <webMaster>{{.}}{{ with $.Site.Author.name }} ({{.}}){{end}}</webMaster>{{end}}{{ with .Site.Copyright }}
    <copyright>{{.}}</copyright>{{end}}{{ if not .Date.IsZero }}
    <lastBuildDate>{{ .Date.Format "Mon, 02 Jan 2006 15:04:05 -0700" | safeHTML }}</lastBuildDate>{{ end }}
    {{ with .OutputFormats.Get "RSS" }}
	{{ printf "<atom:link href=%q rel=\"self\" type=%q />" .Permalink .MediaType | safeHTML }}
	{{ end }}
    {{- range $pages -}}
    <item>
      <title>{{ .Title }}</title>
      <link>{{ .Permalink }}</link>
      <pubDate>{{ .Date.Format "Mon, 02 Jan 2006 15:04:05 -0700" | safeHTML }}</pubDate>
      {{ with .Site.Author.email }}<author>{{.}}{{ with $.Site.Author.name }} ({{.}}){{end}}</author>{{end}}
      <guid>{{ .Permalink }}</guid>
      <description>{{ .Content | html }}</description>
    </item>
    {{ end }}
  </channel>
</rss>

And in config.toml I’ve replaced rssLimit with this…

1
2

[services.rss]
  limit = 20

If there’s an easier way to do all this I’d love to hear about it. Maybe the addition of the new [services.rss] section suggests other pending improvements. Ideally, I wouldn’t need to override the entire RSS template in order to make these changes. And I’ll be sure to read the release notes more thoroughly next time.

Automatic Cross-posting

Should I automatically cross-post from baty.net to all the usual places? I don’t know. Sometimes I feel like I would just be adding noise where no more noise is needed. Other times I figure what the hell, everyone else does it and people seem to love noise. Besides, it’s fun to share.

What I realized was that I often wish some of the people I follow would write more posts or show more photos or otherwise add to my feed. In the unlikely event that there are people out there who feel that way about me, I’ve once again enabled cross-posting. Apologies in advance if you’re not one of them.

Algorithms in NetNewsWire - Brent Simmons

Brent Simmons:

So here’s the thing I keep coming back to: I think of NetNewsWire as almost a kind of ideal public utility. As such, it should be completely trustworthy — you should never wonder if it’s leading you down some path or other you didn’t intend or foresee.

“trustworthy” is a good word and a great feature.

Resurrecting baty.net (for now)

There are two things that cause me to occasionally abandon this blog at baty.net for something else.

The first is friction. Hosting with Hugo is wonderful, but posting can feel like more trouble than it’s worth. That’s when things like Blot or WordPress start to look tempting.

The second is boredom. I love trying new things, so whenever I find some new blogging tool, I trick myself into thinking “This is the one, for real this time!”

So, I stop posting here and add a message letting my handful of readers know where I’ve gone. Of course then I find myself looking something up here that I know I posted some time in the past 15 years and poking around and wondering why I ever left.

Since re-discovering ox-hugo - Org to Hugo exporter, I’ve found ways to reduce the friction of publishing posts. And I love writing in Emacs and Org-mode.

All this to say that I’ve dusted off baty.net, re-jiggered my Hugo setup, and will be posting here again for a while.

Bitcoin

I don’t even resemble an expert in cryptocurrency, but my gut says the whole thing is some sort of mass delusion. I mean, read Twitter after any price fluctuation (up or down), and it’s wall-to-wall rationalization.

These people are just so deeply enamoured with the idea of crypto that they seem to have lost all sense of reason. I don’t want to call them crazy, but I kind of do.

Anyway, I own a little Bitcoin, Etherium, Litecoin, and one other that I don’t remember. I don’t spend more on it than I can afford to lose, but I admit to hedging my bets with the upside potential.

It’s sort of a Pascal’s wager in that if I’m wrong, I still win.

It’s just that my timing is, as always, terrible.

Bitcoin graph