I’m trying to get Cider to work on my laptop running OSX and failing. This makes me unhappy because I managed to do it on a Windows machine with lots of Cygwin so I felt that getting it to work on a Mac should be a breeze.

Basically, what I have set up my little project using lein and can run it from the command line and from eshell, and I use Clojure Mode, but when I run M-x cider-jack-in I see is this in my *Messages* buffer:

Yeah. I think it rewrites the file whenever the system updates? So any code that depends on localhost mapping to 127.0.0.1 usually breaks after an update. Gah!

– Alex Schroeder 2016-12-08 22:59 UTC

Hi Alex, that deletion of /etc/hosts sounds vary odd. I use emacs, cider, lein etc almost daily on OSX and have not run itno that issue ever. I do use hombrew for emacs and lein. I am now running macOSSierra, but have been doing clojure et. al. on a Macbook for the past few years and used the last2 or 3 OSX versions.

– Tim X 2016-12-09 08:30 UTC

Strange. I also have OpenVPN installed on the Mac and it puts stuff into the file. Googling for the problem shows that some versions of a Cisco VPN used to do the same. I should just deinstall it and see whether that resolves it.

Sadly, for the second star, my solution fails… The question is now: which location was visited twice? The example provided says “if your instructions are R8, R4, R4, R8, the first location you visit twice is 4 blocks away, due East.” The code works for the example given but fails for the data I was provided with in the test.

The comments reveal quite a bit of caching issues, though. The problem was that nginx seemed to ignore that two pages with an identical URL but for different language preferences could be different. This in turn meant that a German visitor to a page not in the cache would put the page in the cache but with German menus at the bottom, for example (“Diese Seite bearbeiten” instead of “Edit this page”). And if the next visitor to the same page didn’t understand German, this was annoying.

I thought the answer was that Apache should send the “Vary” header telling the cache that accept-language should be part of the cache key. See this discussion of the Vary header, for example: Understanding the HTTP Vary Header and Caching Proxies. But it just didn’t work.

Recently, I suddenly realized that perhaps nginx doesn’t care about the Vary header Apache is sending. I learned about the proxy_header_key setting in the nginx caching guide. As you can see, the default is inadequate! $scheme$proxy_host$request_uri is not what I’m expecting. I needed to add http_accept_language to that key:

I get the feeling that things are working, right now! If so, it only took 17½ month to find the solution. I’m writing it down in case anybody else stumbles over this problem (and in case I need to remember in the future).

Perhaps the problem is also related to how I compute Etags for my pages: the wiki doesn’t take accept-language into account when computing Etags. Now that I think about it, perhaps that would also have helped solve the problem?

Here is a way to do it combining dired, wdired and multiple-cursors. This approach requires the existence of the album directory which might not make it particularly useful for your exact use case. Still, I find it cool and so should you .

The GPG Agent is a service that will remember your passphrase for a short while. If you don’t use it, Gnus will ask you for your passphrase for every backend it uses (because it needs to log in) and for every encrypted mail you read and for every encrypted mail you send. You’ll be typing your passphrase a lot. You want to use it.

Please let me know if you tried to follow the instructions and it didn’t work. I’d like to make the instructions very easy to follow and troubleshoot. So if you missed something and ran into errors, I’d still like to know so that I can start adding typical problems people might have and how to resolve them.

And finally, feel free to test this system by sending me encrypted email! See Contact for more.

I was able to define my extra stuff using AltGr, which is the equivalent of Alt+Ctrl at the same time, which means that under Windows, I need to press both of them to access @ on g, for example. Is there a way to make this work for both Mac and Windows? Change the Alt key to Right Alt and it’ll work?

When using Emacs, I get A-C-g is undefined. Other programs, like Firefox, will correctly interpret A-C-g as AltGr + g and give me the @. What can I do to fix this?

When using Emacs, I want to use the windows key as meta. On my keyboard, that’s SUP (Super). But in this case, I get some Windows action. So I start experimenting.

Perhaps it would be easier if I changed that key to Meta using the keyboard’s firmware and it would work correctly on both OSX and Windows?

And I’m still not sure how to change bindings for simple keys using the Alt key. Perhaps I need a different utility? A good Microsoft Keyboard Layout Creator alternative…

I guess the alternative would be to use Fn together with these extra keys. But then I can’t bind them to something interesting like “…” because in order to that, I would need access to these keys on Microsoft Keyboard Layout Creator, which I do not.

Well, right now I am back at the US standard layout. Perhaps I can do everything else using dead keys? Might be simpler than all this extra fiddling. I’m hating everything about it already. I’m spending too much time worrying about programming the keyboard but as it stands, I won’t ever get a system, where I can just carry my keyboard to another desk and start typing. It just requires too many features by the operating system and the various solutions are incompatible anyway.

Current mood: frustrated.

– Alex Schroeder 2016-04-11 19:40 UTC

I want a keyboard with Super and Hyper that works on both Windows and OS X. I still don’t have a precise answer but this seems good ot know: https://ergodox-ez.com/pages/our-firmware They define a “Hyper” and a “Meh” key. I pre(re)invented that approach using AutoHotKey and duplicated bindings, and decided it was a poor use of my time. If it is built into your keyboard, however, might be nice. I still want to answer “Why can’t we have a GUI key that is separate from the SUPER key?”. Seems possible, and I would like it a lot because we do need a GUI key, too.

Oh! Right. Whenever I have to use another computer I usually connect to it with my laptop using, er, Synergy. Synergy is great, but… it is an interesting case of a GPL-ed free software getting crippled so that they can sell it…

So I guess that it is just waiting for a fork to appear. Meanwhile you can get a bit older version from here: http://synergy-project.org/download/free/ (or compile it yourself, though in case of crippled software it is usually not as simple. But who knows). Same version is debian repos (so I haven’t really noticed).

It’s kinda interesting that instead of starting some crowd funding they decided to turn the software into something that I don’t really want to recommend to anybody just because of their “monetization“ shit. Awful.

But! It allows me to use my laptop (and therefore my own configuration) for any computer I connect with. So, perhaps that’s an option?

– AlexDaniel 2016-04-11 21:09 UTC

Grant, I saw you blog post just now and I’m reminded of what I discovered when I looked at the keycodes available in the firmware:

No KC_RHYPER or KC_LHYPER! No KC_RSUPER or KC_LSUPER! The comment points to another document: “Keycodes are defined in ‘common/keycode.h’. Range of 00-A4 and E0-E7 are identical with HID Usage.” In the header file mentioned, it says: “Virtual keycodes are defined out of above range to support special actions. Keycodes based on HID Usage Keyboard/Keypad Page(0x07) plus special codes.” As the URLs are no longer pointing anywhere, here’s what I think this refers to the USB HID Usage Tables on page 53ff.

I think this means that there cannot be a USB keyboard with a Hyper key. I think what you therefore need to do is make a key that sends multiple modifiers at the same time, ie. mapping Caps Lock to Shift+Ctrl+Option+Command or something like that. The solution for a Mac involves Karabiner and Seil for OSX. Like the ideas I had myself, this setup is hardly portable to other computers, unfortunately. Apparently, you can do something similar using AutoHotKey.

I’ve been using the Atreus with my la-top at home, using the US standard layout. I use the Latin Prefix input method to write German. This also meant that I no longer require Alt/Option as AltGr and so I use Alt as Hyper again, but have no keys bound using Hyper. Boooo.

– Alex Schroeder 2016-04-24 16:37 UTC

Alex can you show your keyboard layout (like you did up above) showing your current mappings?

I’m confused by your post: did you get what you wanted when you re-configured left and right GUI?

I guessed that you would place LEFT_ALT and where you wanted it to be META, and RIGHT_ALT wherever you wanted it to be ALT. It would look confusing because the keycaps would have ALT all over, but for Emacs, it would be exactly what you want. Right? I think that I might have understood something wrong here.

The end result of all the above is that I am using the default firmware for the keyboard. This means that I’m short one modifier on the Mac: I need the command key to run OSX commands; I need Alt to enter German characters; there’s no key for Meta. Under OSX, the usual solution is to use the Command key as Meta, of possible. So, in order to get that, I would have to swap Alt and Super on the Atreus firmware, assuming I wanted to use my right thumb for Meta. I guess I do?

But the main thing that I wanted to talk about when I replied to your message above was this: All USB keyboards will be limited by the USB standard for keyboards. You can find the necessary information in USB HID Usage Tables on page 53ff. There, on page 59, you’ll note that there is no way a USB keyboard will be able to send the Hyper modifier: There is only Control, Shift, Alt, and “GUI” (Super) for left and right. In order to get Hyper in addition to those present, you’ll have to map your key to something like F13 in the firmware and then you’ll have tell your operating system that F13 should act as Hyper. I think I could figure this out for a GNU/Linux environment, but I’m unwilling to spend the time necessary to figure it out for OSX and Windows.

And so I determined that the two easiest options right now are the following:

don’t use the Atreus keyboard

if I use the Atreus keyboard, use the default firmware, switch to a US layout in OSX, and use something like the following for Emacs:

But, I don’t like any of it and I’m unhappy with the current state of affairs. The sad part is that I don’t see an easy way forward. Maybe during my summer break.

– Alex Schroeder 2016-05-15 00:19 UTC

Gotcha. I am sorry that it isn’t going as planned. Here is what I tried https://www.wisdomandwonder.com/article/10146/every-emacser-can-use-hyper-on-every-usb-hid-keyboard . This is how I came up with “using hyper in Emacs” given that there are only 8 modifiers (left or right, shift control alt gui) in the USB HID spec and there is no xmodmap option for Windows. It seemed happy on my Mac and Windows box; I tried the following on both boxes. The important thing for me was that Windows and OS X had their important modifiers: ALT and GUI so I could switch window focus and use OS actions like inserting special characters and opening the Run dialog in Windows. I read your post like it would work the same way for the Altreus. The way I read your post I figured that you MIGHT modify your default keyboard https://atreus.technomancy.us/ by changing the default layout (by names there): super as RIGHT_GUI (aka option), ctrl as RIGHT_CONTROL, alt as RIGHT_ALT (aka command), and then moving - ‘ , to the Fn layer, so you can redefine - as LEFT_CONTROL (Meta), ‘ as LEFT_ALT (Super), and , as LEFT_GUI (Hyper) only for Emacs using the mac-right-*modifier and mac-left*-modifier settings. I didn’t want the CONTROL-ALT-GUI-SHIFT style hyper key since I only want these modifiers in Emacs. I tried that approach and didn’t like it only because I only wanted the modifiers inside of Emacs. If things work like I am seeing them work on the Mac, then this will work on your Altreus. Otherwise I am wrong and need to revise my post ASAP.

Right now I’m trying to get used to the US keyboard layout again. This requires some changes in my motor patterns. The Atreus keyboard with standard config is here, next to the laptop, but I rarely use it.

In my Gmail Gnus GPG Guide I don’t mention gpg-agent because I never managed to set it up correctly for OSX.

Well, perhaps things will change. I followed the instructions on this blog post, I think, and it works on the command line. I can encrypt a text to myself, when I decrypt it, I’m asked for my passphrase, and when I decrypt it again, I’m not asked for my passphrase because the agent handles it.

This requires my gpg-agent.conf file to contain the line pinentry-program /usr/local/bin/pinentry which is the equivalent to pinentry-curses.

Within Emacs

Without the agent running, and with pinentry-mac, it would work from within Emacs (which is what I want to get working). When the agent is running, no matter what the pinentry-program line says, it won’t work.

I’m guessing this is a pinentry problem. Not exactly the same string, though. So… Any ideas? What’s wrong? Should I be setting GPG_TTY? The problem appears to be that if I don’t use gpg-agent, Emacs using gpg knows how to call pinentry-mac. If I do use the gpg-agent, then the gpg-agent tries to call pinentry-mac and fails.

Currently the environment for my Emacs session has the following, as determined by running printenv in *eshell*:

GPG_TTY=not a tty
GPG_AGENT_INFO=/tmp/gpg-oqrtL2/S.gpg-agent:40161:1

That looks wrong… I’m surprised that GPG_TTY is set in the first place. I’m setting it in my .bashrc file! So starting Emacs uses a shell? I don’t know how Emacs does that.

Within Emacs, I used setenv to set the GPG_AGENT_INFO to the new value, and it worked: I could open my test file, got asked for my passphrase, killed the buffer, reopened it, and was no longer asked for a passphrase.

So now I’m going to revert the addition of --pinentry-program to the start-gpg-agent.sh script, and see whether simply killing and restarting it from a terminal also “fixes” it. And then we’ll start worrying about the difference between all this stuff.

OK, so restarting this Mac apparently “fixed” all the issues I was having.

Haha, “This is probably totally insecure, and your passphrase may be leaked! Use at your own risk!” Also, what happens when you’re in a terminal and use gpg – does it start Emacs, or the Emacs Client, and thus you need to be running Emacs somewhere?

– Alex Schroeder 2016-03-18 21:32 UTC

There is also an ELPA package called “pinentry”; as the note in the package description says, it works “with GnuPG (2.1.5+) and Pinentry (not yet released, possibly 0.9.5+)”. It works here.

Thanks for this, Alex. I don’t write Javascript often, and had never been sufficiently motivated to figure out why (local-set-key (kbd "RET") (key-binding (kbd "M-j"))) was so broken for Javascript block comments. Presumably js-mode should actually be binding M-j to c-indent-new-comment-line

– Anonymous 2016-03-07 03:41 UTC

…in fact I see that it’s the combination of (setq-local comment-multi-line t) and (local-set-key (kbd "RET") 'c-indent-new-comment-line) which fixes this, rather than the command alone. (So that comment-multi-line setting is important for both the indent-new-comment-line behaviour and the auto-fill behaviour).

OK, so that explains comment-multi-line. I still thought I had a good solution for auto-fill-mode and now it seems that I don’t. Looking at do-auto-fill it seems that fill-context-prefix finds no prefix. It determines first-line-prefix to be the empty string and second-line-prefix to be “ * “. So why isn’t it used?

There’s this test: (string-match re first-line-prefix) with re being \`.*\*". So where’s the problem? Should first-line-prefix be /** such that this test succeeds and second-line-prefix is picked? Because now we’re getting to “the longest common substring of both prefixes” resulting in the empty string.

It seems to me that fill-match-adaptive-prefix ought to return /** and it does not. There, we find (looking-at adaptive-fill-regexp) which matches and (match-string 0) which returns the empty string.

Sooo… (setq adaptive-fill-regexp "[ ]*\\(//+\\|/?\\**\\)[ ]*\\([ ]*\\([-–!|#%;>*·•‣⁃◦]+[ ]*\\)*\\)") fixes this by inserting /?. The segment in question is from c-comment-prefix-regexp which is set to //+\\|\\**. Now what? It’s doc string says: “it does not need to match a block comment starter” Does it?