Even though it’s been one of my most time-consuming projects, I’ve hardly blogged about racket-mode — an Emacs major mode for Racket. To change that, here’s a post giving an overview of how racket-mode works, as well as a look at how it might grow someday.

In my previous post I discussed what I’m doing with deals.extramaze.com — and what I’m intentionally not doing. Since then, I’m not-doing more. This improves performance and simplifies the content security policy.

For Extramaze LLC I’m using Racket in a commercial project — a search engine with email alerts for deals on music gear — deals.extramaze.com.

This blog post is a sort of whirlwind tour of the use case and business model, as well as how I use things like Racket, PostgreSQL, and AWS — but don’t use advertising or JavaScript.

A few years ago I wrote about makefiles for Racket. Some things have changed.

1. The old makefile built and pushed documentation to a GitHub Pages branch of the repo. That’s no longer necessary: The Racket package catalog builds and hosts documentation.

2. The Racket package catalog puts a yellow badge of shame on packages with missing dependencies (deps and build-deps in the package’s info.rkt). I want the makefile to check this.

3. In .travis.yml files for Travis CI, I think the script section ought to simply invoke targets in the makefile — delegating details to the latter.

4. Likewise some details needn’t even be in the makefile — they can move to the collection’s info.rkt. Example: The list of directories to clean.

5. The old makefile had separate PACKAGENAME and COLLECTS variables; for single-collection packages they were the same value. I wanted to simplify this to just the package name and use the appropriate package variants of raco commands.

In that spirit, here’s an updated Makefile, which I recently started using in the rackjure, markdown, and frog projects.

Recently I got more time to catch up on racket-mode. I improved two things that happen to fit one theme — an extraordinarily advanced UX concept I call, “scrolling down to the point of interest.”

Until a few months ago I didn’t use Emacs themes. A custom-set-faces form in my init file gradually accumulated face specs like a lint-roller.

Then I started to use Solarized. Mostly light, sometimes dark. Switching between them using M-x load-theme worked fine.

Later I liked the look of Material. Although too high-contrast to use full-time, it works well in certain situations.

After I installed it I had two annoyances:

1. I didn’t love the 3D “button” look it gives org-mode headings. Must tweak.

2. Switching between the Solarized and Material themes using load-theme definitely did not work well: If the old theme defined a face, but the new theme did not, the old face would remain in effect. So for example I might switch to Material then back to Solarized, and get a weird mix of mostly Solarized but with Material org headings.

Here’s what I’m doing to address both issues.

If you’ve heard of Racket “at-expressions”, maybe you think they’re “that funny Scribble notation in which you write Racket documentation.”

In fact at-expressions are a general, alternative way to write s-expressions. They can be used in various handy ways.

Let’s look at using at-expressions for a few practical things like:

• “string interpolation”
• regular expressions
• “here” strings

This revises my Keyword structs post to fix some mistakes, discuss the struct* match pattern, and rewrite the macro to use syntax-parse and support default arguments.

A good rule of thumb in Racket is to use a struct instead of list when you’re juggling more than two or three items.

It’s been a few weeks since I’ve blogged. Bad me. This is a catch-up post.

Hacker School has a tool called Blaggregator created by Sasha Laundy. We can submit feeds for our blogs. Blaggregator provides an aggregate page, and puts new-post messages on Zulip, the chat tool.

My first-ever open source contribution, a couple years ago, was to a project called Pygments. My motivation? GitHub was displaying Racket source code poorly. Pygments didn’t have a Racket lexer. GitHub was using a Scheme lexer for Racket code. The Scheme lexer was highlighting square brackets in red as an “error”. This was really distracting and ugly.

I contributed a new Racket lexer to Pygments, and waited for that to roll into a Pygments release and in turn be deployed on GitHub. Finally Racket code looked good! Later Dave Corbett substantially improved the Racket lexer beyond my small start.

A few days ago, I was confused to see that Racket code was displaying poorly again on GitHub. The square brackets were highlighted in red as errors — again??

Cartoon-me’s thought balloons: WAT, OMFG, FML, &c. Why are we going in circles?