How do you do this in Doom Emacs? By adding the following snippet to your config.el file:

(after! evil
  (setopt evil-escape-key-sequence "jk"))

By using Doom’s after! macro you ensure your change to the escape key sequence doesn’t get overwritten by Doom’s default configuration.

1. Add org-jira to my ~/.config/doom/packages.el file:

   (package! org-jira)
   

2. Create a PAT in Jira
3. Store my Jira PAT in my ~/.authinfo file
4. Configure org-jira in my ~/.config/doom/config.el file:

   (use-package! org-jira
     :config
     (setq jiralib-url "<my-jira-url>")
     (setq jiralib-token
        (cons "Authorization"
              (concat "Bearer " (auth-source-pick-first-password
                                 :host "<my-jira-url>")))))
   

I’m not entirely sure why, although I think these things helped:

• LSP support
• Lots of Doom modules have flags to add additional functionality e.g. (ruby +rails +rbenv +lsp) to add Rails, rbenv support, and add LSP integration to the Ruby module
• Projectile
• Setting up the built in terminal emulator to use vterm
• Org Mode

There are several ways to prevent your site from becoming part of the FLoC network, you just need to pick the one most appropriate for your setup. As I host this site on GitHub Pages, all I needed to do was add a <meta> tag to the head of my page like so:

<meta http-equiv="Permissions-Policy" content="interest-cohort()">

Et voilà! FLoC off.

<label for="numbers-and-special-chars">Enter numeric code</label>
<input id="numbers-and-special-chars" type="number">

To get the number only keypad you also need to add the pattern attribute, and set its value to [0-9]* like this:

<label for="numbers-only">Enter numeric code</label>
<input id="numbers-only" type="number" pattern="[0-9]*">

It’s relatively easy to add it to an existing docker-compose.yml file. You add localstack as a service, and tell it to use one of the localstack images:

services:
  localstack:
    container_name: localstack
    image: localstack/localstack 

You can specify which services you need using the SERVICES environment variable e.g. if you’re only using SNS and SQS you might do something like this:

services:
  localstack:
    container_name: localstack
    image: localstack/localstack 
    environment:
      - SERVICES=sns:4575,sqs:4576

This runs sns on port 4575, and sqs on port 4576. You can expose those ports in the usual way, and set an HOSTNAME_EXTERNAL environment variable if you need to:

services:
  localstack:
    container_name: localstack
    image: localstack/localstack 
    environment:
      - HOSTNAME_EXTERNAL=localstack
      - SERVICES=sns:4575,sqs:4576
    ports:
      - "4575:4575"
      - "4576:4576"

The LocalStack container comes with awslocal installed by default, which is handy to use in a healthcheck to make sure your queues, etc. are available before your application code tries to use them:

services:
  localstack:
    container_name: localstack
    image: localstack/localstack 
    healthcheck:
      test: awslocal sns list-topics && awslocal sqs list-queues
      interval: 3s
      timeout: 10s
    environment:
      - HOSTNAME_EXTERNAL=localstack
      - SERVICES=sns:4575,sqs:4576
    ports:
      - "4575:4575"
      - "4576:4576"

Note that when using awslocal it will default to the us-east-1 region unless you set the AWS_DEFAULT_REGION environment variable to your region of choice:

services:
  localstack:
    container_name: localstack
    image: localstack/localstack 
    healthcheck:
      test: awslocal sns list-topics && awslocal sqs list-queues
      interval: 3s
      timeout: 10s
    environment:
      - AWS_DEFAULT_REGION=eu-west-1
      - HOSTNAME_EXTERNAL=localstack
      - SERVICES=sns:4575,sqs:4576
    ports:
      - "4575:4575"
      - "4576:4576"

Comprehensive details of what LocalStack provides, and on how you can configure it, are available on the LocalStack GitHub repo: https://github.com/localstack/localstack

Hopefully the above is enough to get you up and running.

Lots of advice online suggests either making sure you launch tmux using tmux -2, or adding set -g default-terminal "screen-256color" to your ~/.tmux.conf file. Neither of these fixes worked for me, although YMMV.

What did fix things for me was adding terminal overrides to ~/.tmux.conf like so:

set -ga terminal-overrides ",*256col*:Tc"

Huge thanks to rineth for their helpful post.

Jekyll layer

I write this blog using Jekyll, so I’ve added a Jekyll layer to make managing posts a bit easier. You need to add it as a private layer, and it acts as a wrapper around Hyde with some Spacemacs key bindings.

dotspacemacs-major-mode-leader-key

Spacemacs comes with a dotspacemacs-major-mode-leader-key variable, which defaults to ,. This acts as a shortcut to access the major mode SPC m commands. However, I didn’t know about this when I setup Spacemacs and remapped my leader key to ,. Consequently, when I tried to schedule an item in org mode I couldn’t work out why it didn’t schedule the item but opened a new email with my whole org file in it as HTML :thinking:

To get around this I’ve updated my .spacemacs file and set dotspacemacs-major-mode-leader-key nil in dotspacemacs/init.

Things I really like about it so far include:

1. That any Git repo automatically becomes a project
2. The recent projects list / project switcher
3. Fuzzy finding logic when opening a file in a project (I’m used to using fzf with Vim, so this has so far been a seemless replacement)
4. The ease with which it kind of sets itself up for you when you open a file of a particular type (I opened a HTML file for the first time it offered to install the HTML layer which comes with emmet-mode and loads of useful key bindings)
5. Org mode
6. Key binding discovery :heart:

I’ve come across a few snags though:

1. Org mode wouldn’t quite work out of the box. I had to exclude the org-projectile package, and ensure I was not using the built-in org mode.
2. Keyboard shortcuts when using the shell layer are all kinds of messed up. I suspect it’s some sort of conflict between the Emacs shell commands and the Evil layer / commands and need to spend some time figuring out what’s what.

Time will tell whether I stick with Spacemacs, or revert back to Vim. So far though, so good.

$> node -v
v9.5.0
$> brew unlink node
$> brew link --force node@8
$> node -v
v8.9.4

Although you can use dedicated tools to manage your Node.js versions, I’ve got by just fine using Homebrew’s link and unlink commands:

1. Homebrew’s node package points at the latest version of Node.js. You can find out exactly which version by running brew info node:

   $> brew info node
   node: stable 9.5.0 (bottled), HEAD
   ...
   

2. Install node using brew install node

3. Homebrew formulae are available for prior versions of Node.js and follow the node@<version> naming convention. You can see exactly which version of Node.js a formula points to by using the info command:

   $> brew info node@8
   node@8: stable 8.9.4 (bottled), HEAD [keg-only]
   ...
   

4. Install node@8 using brew install node@8

5. With node and node@8 installed we can switch between them like so:

   $> node -v
   v9.5.0 # <- node is pointing at the node formula
   $> brew unlink node
   $> brew link --force node@8 # --force required as node@8 is a keg-only formula
   $> node -v
   v8.9.4 # <- node now points at the node@8 formula
   

6. To change back to the latest Node.js, just do the opposite to what we’ve just done:

   $> brew unlink node@8
   $> brew link node
   $> node -v
   v9.5.0