Right now tunnel boring machines are expensive and we only use them for a few projects. If they were cheaper we'd have a lot more of them and use them for many more roads.

I've long wanted tunnels for lightweight freight transportation (see my blog post from 2005) but I'd also like tunnels for infrastructure in general — electricity, gas, water, gray water, cable tv, telephone land line, fiber optic internet, mail delivery, trash collection, etc. It's a shame that we have to dig up roads to install or fix any of these. It's a shame that I can't get gray water for my yard and am using drinking water to water my flowers. It's a shame that fiber optic internet access is so expensive to install. It's a shame that we have to see ugly power/telephone/cable lines everywhere. Also, a lot of this stuff would be better out of the weather.

Cheap tunnels would change a lot of things! I'm hoping Elon Musk will make this happen!

Org mode 9 was just released, and it changed the syntax for export blocks. I need to change:

#+begin_html
…
#+end_html

to

#+begin_export html
…
#+end_export

The Org mode changes file includes some elisp to change this. However, I couldn't get it to work, and I also wanted to change all my files, not run this elisp on one file at a time. Here are the commands I ran:

Idea: when at at Chinese restaurant, use facial recognition and/or tap into vast databases of personal information linked to your credit card to gather lots of information about the people at the table, then use deep neural networks to write a custom fortune for each person, then use focused microwaves to print these on blank pieces of heat-sensitive paper embedded inside fortune cookies. Then when you get your fortune cookie, it'll be personalized just for you. Maybe it could be a targeted ad!

On Mac OS X, there's a fantastic tool called Karabiner (previously KeyRemap4MacBook) that lets you control how your keyboard and mouse work — things like keyboard repeat rate, mouse acceleration, arrow keys, function keys, control/escape/shift/option/fn, adding keys to enter unicode characters, and many other things. I use it primarily for remapping the function keys. On my laptop, I want F1,F2 to control brightness, F3,F4,F5,F6,F7,F8,F9 to be function keys, and F10,F11,F12 to control volume. Mac OS X offers in the System Preferences a choice of having them all be function keys or all be special functions. I want five to be special functions and seven to be function keys. Karabiner lets me do that.

Karabiner's standard settings dialog lets me swap just some of these keys. First, I told Mac OS X to make them all function keys. Then in Karabiner, I selected

Change F1..F19 Key & Functional Key

Change Functional Key

Fn+Functional Keys to F1..F12

[X] Fn+Brightness Adjust to F1,F2

[X] Fn+Speaker Controls to F10,F11,F12

Change F1..F19 Key

F1..F12 to Functional Keys

[X] F1,F2 to Brightness Adjust

[X] F10,F11,F12 to Speaker Controls

Great! It now behaves how I want.

Except… I want more! Once I got an external keyboard, I wanted the function keys to behave differently. The external keyboard has its own volume keys, so I don't want them swapped there. I use it with an external display, so the brightness keys aren't useful to swap.

Karabiner offers an XML configuration file when the standard settings dialog isn't enough. Reading the XML file format documentation, I saw that I can restrict certain settings to only run in some apps or some devices. I came up with this equivalent for the above settings (and then later realized all the built-in settings have XML files like this one):

However, I want to swap these keys only on the laptop keyboard. I used Karabiner's Event Viewer helper application to figure out that my laptop keyboard's device id was 0x0259. I could then modify the settings to only apply to my laptop keyboard:

I also solved another annoyance. My external keyboard always sends number keys from the number pad, and I'd rather send arrow keys. Karabiner can do that too. I had to find the device vendor and product id from the event viewer, and then I used these settings:

I think there are too many types. I don't use 10¢, 50¢ coins, nor do I use $2 $10 $50 bills. Why?

I think what I want is for each size to be 4 or 5 times as big as the previous size. My simplicity-preferring brain doesn't like to see a $2 bill when two $1 bills is not that much more to carry. I don't like to use a $10 bill instead of two $5 bills. Carrying five $1 bills is a bit much and then I'm happy to carry a $5 bill instead. Two or three isn't enough to trigger this desire; four or five is enough.

If we started with 1¢ and stepped up by a factor of 4 or 5 each time, then the sequence would be 1¢ 5¢ 25¢ $1 $5 $20 $100. These are the ones I actually use in practice. For Euros we could have 1c 5c 20c €1 €5 €20 €100 €500.

Let's drop 10¢ coins and $10 bills and treat them like 50¢ coins, $2 bills, $50 bills — they exist but we don't use them widely.

Back in 2014 I posted my emacs setup for finding files globally. It acts like switch-to-buffer, if all the files on my system were already open in buffers. I can type in a substring of any filename I'm likely to work on and switch to that buffer. Since them, helm has changed its interface, and I've updated my code, adding a few extra quality-of-life features.

I use the same hourly cron job to take inventory of all files I am likely to edit, putting recently modified files near the top, as they are most likely to be the best match. I save this list to ~/.global-file-list.txt.

What's changed is how I set up helm. In 2014 I was using helm-recentf and temporarily binding the recentf file list to my own list. This was a quick & dirty way to do it, and it worked, except when I opened a file, it didn't get put onto the recentf list, since I had let-bound that list to something else. Oops. I learned more helm (by reading the source code and John Kitchin's blog posts) and now construct my own helm source instead of abusing helm-recentf:

This source tells helm to call amitp/helm-global-file-list. This function returns the most recently modified files at the top, then the currently open files, then files in the current folder, then recently opened files, then the global file list. (I'm not happy with this order and am still experimenting.) Some filenames will be in more than one list so I eliminate duplicates.

I also use a filter to remove some filenames from the list. Why? Normally I want to show only the “source” and not the “compiled” version of something. For example I want to show .el files but not .elc files. I want to show .c files but not .o files. I can hide these with helm-boring-file-regexp-list. However, for my web pages, some of them are directly written as .html files (*.html should be included) but others are written in Org mode or markdown or something else (*.html should be excluded). To decide whether a file ending in .html is source or not, I need to look at the other filenames in the list. I use a “filtered candidate transformer” (see the documentation for helm-source) to take the currently matching filenames and filter them further. If the filenames contain both$something.org and $something.html then I know that the html is not a source file, so I hide it.

I don't currently colorize the output. I've considered coloring by type (source code, prose, build file, etc.) and by origin (recentf, current folder, open buffer, global list) but neither of these seems particularly appealing. I'll continue to experiment.

The last change since 2014 is that my global file list doesn't have everything, and it is annoyingly missing any new files I've created in the past hour. In 2014 I set up C-l to switch to helm-locate so that if I was unable to find what I wanted, I could have it search more. However, I never remembered to use it.

I now have two ways to solve that problem. First, I augment my hourly cron job with a quick cron job that runs every minute, and reports back any files edited recently. I had started with any files added recently but realized if I changed it to files edited recently, I could put those files at the top of my list. I run this every minute:

In the helm source, I read ~/.recent-file-list.txt (a very short list) and put those items ahead of others.

The second solution is to use helm-source-locate as a source in the main interface, even though the UI is incompatible (for regular results you can use space to separate words, but for locate you can't). It will show the locate results below the main results. For times when my global file list and my recent file list don't show anything, locate might find it.

(setq helm-locate-command "/Users/amitp/bin/locate %.0s %s")

I use Mac's mdfind (which is updated in real time) to find the base filename and then I filter that through grep to handle folders. For example, if I run locate foo/bar then I use mdfind to find files named bar, then in the results I grep for foo/bar. However if I run locate ar without a folder name then I should find bar as a substring match. The shell script isn't perfect but it's “good enough” for now.