I’m writing and publishing this post using something other than Frog.

Having said that, I’m not planning to abandon maintaining Frog.

Sometimes people want Racket threads to have useful names — for example to show in logger output. Here is one way to do it.

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.