Mickey Petersen author of the the excellent book Mastering Emacs and the blog of the same name has another of his comprehensive and informative articles on his blog. This time it’s about tree sitter and its application to syntax highlighting in Emacs.

Even though we take it mostly for granted, syntax highlighting is actually a devilishly difficult problem. Emacs and almost every other editor does it with a witches’ brew of regular expressions and ad hoc functions. The results are usually, but not always, good enough. The correct method, of course, is to build a syntax tree of the code and use that to inform the highlighting. There’s a whole host of problems with that approach. In the first place, the code you’re editing probably isn’t syntactically correct because it’s incomplete. Secondly, the naive solution of rebuilding the tree with every keystroke is too slow to be practical and there are other problems as well.

Mickey has a solution: use tree sitter to drive the highlighting. If you don’t know about tree sitter or what it’s used for, head on over to Mickey’s post for the details. Tree sitter can do more than just figure out syntax highlighting. Mickey mentions the excellent ParEdit and its use in Lispy languages. Mickey wanted to extend that capability to other languages, Python in particular.

He’s built a package to do just that. He calls it combobulate. It’s still alpha software but you can try it out if you like. Mickey says he’ll put it on Melpa as soon as he works out a few more issues. Mickey believes that the tree sitter approach is the future for addressing these types of problems.

I know I keep saying this but tree sitter and Emacs’ embrace of it once again puts the lie to the notion that Emacs is moribund technology. The reverse is true. Emacs keeps introducing new capabilities that other editors copy and then use to support their claims of superiority.

In a tool I'm writing I want to load a file that may reside on the local disk, but if it isn't there I want to fetch it from the web. Basically it's very similar to having a cache and dealing with a miss, except in my case I don't populate the cache.

Let me first define the functions to play with

loadFromDisk :: String -> IO (Either String Int)
loadFromDisk k@"bad key" = do
    putStrLn $ "local: " <> k
    pure $ Left $ "no such local key: " <> k
loadFromDisk k = do
    putStrLn $ "local: " <> k
    pure $ Right $ length k

loadFromWeb :: String -> IO (Either String Int)
loadFromWeb k@"bad key" = do
    putStrLn $ "web: " <> k
    pure $ Left $ "no such remote key: " <> k
loadFromWeb k = do
    putStrLn $ "web: " <> k
    pure $ Right $ length k

fallBack ::
    Applicative m =>
    m (Either String res) ->
    m (Either String res) ->
    m (Either String res)
fallBack = liftA2 (<|>)

λ> loadFromDisk "bad key" `fallBack` loadFromWeb "good key"
local: bad key
web: good key
Right 8

λ> loadFromDisk "bad key" `fallBack` loadFromWeb "bad key"
local: bad key
web: bad key
Left "no such remote key: bad key"

λ> loadFromDisk "good key" `fallBack` loadFromWeb "good key"
local: good key
web: good key
Right 8

λ> loadFromDisk "good key" `fallBack` undefined
local: good key
*** Exception: Prelude.undefined
CallStack (from HasCallStack):
  error, called at libraries/base/GHC/Err.hs:79:14 in base:GHC.Err
  undefined, called at <interactive>:451:36 in interactive:Ghci4

fallBack ::
    Monad m =>
    m (Either String a) ->
    m (Either String a) ->
    m (Either String a)
fallBack first other = do
    first >>= \case
        r@(Right _) -> pure r
        r@(Left _) -> (r <|>) <$> other

λ> loadFromDisk "bad key" `fallBack` loadFromWeb "good key"
local: bad key
web: good key
Right 8

λ> loadFromDisk "bad key" `fallBack` loadFromWeb "bad key"
local: bad key
web: bad key
Left "no such remote key: bad key"

λ> loadFromDisk "good key" `fallBack` undefined
local: good key
Right 8

fallBack ::
    (Monad m, Monoid e) =>
    m (Validation e a) ->
    m (Validation e a) ->
    m (Validation e a)
fallBack first other = do
    first >>= \case
        r@(Success _) -> pure r
        r@(Failure _) -> (r <|>) <$> other

mFromRight :: MonadPlus m => m (Either err res) -> m res
mFromRight = (either (const mzero) return =<<)

firstRightM :: MonadPlus m => [m (Either err res)] -> m res
firstRightM = asum . fmap go
  where
    go m = m >>= either (const mzero) return

λ> firstRightM [loadFromDisk "bad key", loadFromWeb "good key"]
local: bad key
web: good key
8

λ> firstRightM [loadFromDisk "good key", undefined]
local: good key
8

λ> firstRightM [loadFromDisk "bad key", loadFromWeb "bad key"]
local: bad key
web: bad key
*** Exception: user error (mzero)

λ> firstRightM [loadFromDisk "bad key", loadFromWeb "bad key"] <|> pure 0
local: bad key
web: bad key
0

firstRightM ::
    (Foldable t, Functor t, Monad m, Monoid err) =>
    t (m (Either err res)) ->
    m (Either err res)
firstRightM = runExceptT . asum . fmap ExceptT

fallBack ::
    (Monad m, Monoid err) =>
    m (Either err res) ->
    m (Either err res) ->
    m (Either err res)
fallBack first other = runExceptT $ ExceptT first <|> ExceptT other

λ> loadFromDisk "bad key" `fallBack` loadFromWeb "good key"
local: bad key
web: good key
Right 8

λ> loadFromDisk "good key" `fallBack` undefined
local: good key
Right 8

λ> loadFromDisk "bad key" `fallBack` loadFromWeb "bad key"
local: bad key
web: bad key
Left "no such local key: bad keyno such remote key: bad key"

asum :: (Foldable t, Alternative f) => t (f a) -> f a
asum = foldr (<|>) empty

2021 is the year of anniversaries for me:

• 10 years since the creation of my first OSS project Projectile
• 10 years since the creation of my second OSS project Emacs Prelude
• 10 years of using Zenburn as my Emacs color theme.
• 10 years since I’ve stopped using Linux as my primary desktop operating system
• 10 years since I bought my first Kindle
• 10 years since I’ve started blogging like with a hacker with Jekyll

Probably I’m forgetting some other important anniversaries, especially those that were not related to technology. 2011 was a really big year for me!

Today I’d like to look back on my experience with Jekyll, the static site generator (SSG) that I’m using to publish this site and my other blogs Meta Redux and Emacs Redux. Back in the day Jekyll was a trend-setter - it basically defined the SSG category and every subsequent tool in it was compared to Jekyll. A lot has happened since 2011:

• Jekyll has a ton of great alternatives today (e.g. Hugo, Ghost, Cryogen, etc)
• For a while Octopress was all the rage in the world of Jekyll (basically Octopress was a highly customized Jekyll setup that many people were using, including me)
• Jekyll’s development lost momentum over time. For a while the project was supported by GitHub engineers directly, but I believe this is no longer the case.
• Ruby was all the rage back then, now that’s no longer the case. Part of the allure of the alternatives is that they are not based on Ruby and supposedly are easier to use as you don’t have to deal with gems, Gemfiles, etc.

I definitely had a troubled relationship with Jekyll myself. Early on I was quite annoyed that you had to setup everything in Jekyll manually, even basic things like an Atom feed or archive/tags pages. I was also frustrated that I had to fiddle with the themes a lot, as HTML and CSS were never my strong suites. If I recall correctly the early versions of Jekyll used some horrible Markdown parser that caused all sorts of problems for me. Still, for all its shortcomings Jekyll was a huge win for me as it allowed me to do exactly what I wanted to do:

• Write my articles in Emacs using my beloved Markdown format.
• Store my blog under version control and treat it like any other software project.
• Host my blog for free on GitHub Pages.

I guess the first point was the only important point, though. When it comes to writing there’s a single tool I want to use everywhere and that’s Emacs. In hindsight I realize that Jekyll and Emacs are quite similar in some ways - they are both building material and not some end user products. Jekyll is a framework for building sites and this requires you to invest a lot in tweaking the setup to your liking. Emacs is a framework for building the ultimate editor. We’ve already established numerous times that’s a life-long endeavor.

Over the years I considered replacing Jekyll with something else a few times, especially when Hugo was all the rage and I was still stuck with a semi-broken Octopress setup. I remember playing with Hugo and thinking that it’s not really that different from Jekyll. Sure, it generated sites faster, but I never cared much about this. Frankly, I almost never run Jekyll locally - I simply write and push to GitHub when I feel I’ve written something that’s already in a readable form. Production is my preview - unlike with software I think for blogs that’s fine. The fact that Jekyll is written in Ruby is a problem for most people, but for me it’s a feature. After all, I was a Ruby programmer back in 2011 and I still involved with Ruby to this day.

Most importantly, however, Jekyll is as simple as it gets. I guess pretty much everyone can setup a Jekyll blog in 5 minutes if they don’t need to do customize some theme. When it comes to writing the thing that truly matters is the content and not its appearance. The more time you spend on customizing your blogging tool, the less time you have for the actual process of writing.¹ Jekyll gets the job done for me and I simply don’t want to invest a lot of time to learn properly another SSG (e.g. Hugo) when I can be writing new articles instead. Time is our most precious resource and the older I get the more I value it.

I’ve had a productive decade with Jekyll, sans the end of the Octopress era, and I think I won’t be moving away from Jekyll any time soon. Yeah, there’s always some room for improvement and probably many of the newer tools do the job better in our area or another, but Jekyll covers well my use-cases and that’s what matters the most to me. I recall back in my Linux days I spent countless hours doing distro-hopping, with the misguided notion that some Linux distro will be massively better than all the others. A classic example of missing the forest for the trees. At this point I’m fairly certain that no SSG is significantly better than the alternatives and the only practical differences for me are their communities and how much do I have to learn to use one of them.

And that’s a wrap. This happens to be the 132th article I publish here since adopting Jekyll. I’ve also published exactly 280 articles on “Emacs Redux” and “Meta Redux”. Here’s to the next 10 years of blogging with Jekyll and Emacs! I hope I’ll do better this time around.²

Some days ago I briefly wrote about my willingness to give Emacs built-in VC system a try for real. For real means that it’s easy to praise the beauties of vc-git when working on personal projects such as this blog, but is VC actually worth it on bigger projects where different people commit and push regularly, rebasing is a habit, and merge conflicts are unavoidable necessities?

A warning first. This article is not intended as a VC tutorial. It aims to be an example of how I use it or, to phrase it better, how I started to use it. As Mickey Petersen suggests in the “Exploring Emacs” section of his great Mastering Emacs book, if you want to know more about VC there is plenty of information right within our favourite text editor. Furthermore, Protesilaos Stavrou has a couple of nice videos on VC you might want to check out: Introduction to VC and Workflow with VC for Git.

Now, let’s break down a common workflow of mine:

• A new ticket is assigned to me
• I create a new branch for this ticket, starting from the master one
• I code my thing
• I commit and push my code
• I file a new merge request ready to be reviewed
• The review may require changes to my code
• I may need to rebase my changes onto master because other developers have merged their branches before me
• Merge conflicts may arise and need to be fixed
• I push my updated code ready to be reviewed again
• If everything’s fine I merge my changes, otherwise back to my edit/rebase/merge process until it’s properly done
• Meanwhile, it may happen that I need to stash my changes and quickly fix a higher priority bug

This more or less happens on a daily basis, so the interaction with Git (the only VCS I have used in the last ten years) must be smooth. On the other hand, Git-wise the above workflow is not that complicated. For instance, I rarely use features such as cherry-picking or bisecting.

On the surface, the main difference between Magit and VC is transient. Magit transient menus make all the operations I described above¹ a breeze. From checking out a branch to interactive rebasing, Magit requires few key strokes to accommodate my needs. The blatant truth is that Magit wraps everything I want from Git and much more in a user interface that just works.

VC, however, is not tightly coupled to Git, so it does not cover all of its many options. And yet I was able to manage my work projects with VC alternatives to Magit commands.

VC has its own vc-git-stash, vc-git-stash-pop, and vc-git-stash-delete commands, but instead of calling them via M-x every time I devised mu-vc-git-stash and bound it to z in vc-dir-mode-map:

(defun mu-vc-git-stash (pop-or-delete)
  "Create, pop, or delete Git stashes.
With no POP-OR-DELETE call `vc-git-stash'. With one prefix
argument call `vc-git-stash-pop'. With two prefix arguments call
`vc-git-stash-delete'."
  (interactive "P" vc-dir-mode)
  (cond ((= (prefix-numeric-value pop-or-delete) 4)
         (call-interactively #'vc-git-stash-pop))
        ((= (prefix-numeric-value pop-or-delete) 16)
         (call-interactively #'vc-git-stash-delete))
        (t (call-interactively #'vc-git-stash))))

As you can see, C-u z issues vc-git-stash-pop while C-u C-u z runs vc-git-stash-delete.

One thing that Magit really shines at for me is interactive rebasing (r i). I haven’t had the opportunity so far to check how I can handle this with VC. I guess a combination of shell-command and something I have yet to discover would do, probably.

Anyway, I’ll keep using VC in the next days and report back if I manage to adapt more of my Git workflows to it. I suspect Magit will outshine the humbler Emacs built-in eventually, but who knows. Reading on the emacs-devel mailing list that some wild Emacs developers prefer VC to Magit seems to confirm that the world is still full of surprises.

Notes

Bozhidar Batsov made an interesting observation that several people have mentioned or commented on. The TL;DR is that Batsov thinks that Emacs can be considered a lifestyle. If you’re an Emacser your reaction is probably like mine: it’s not literally true but it does capture a certain truth concerning how we feel about Emacs.

For me, the essence of that feeling is captured by Stephen Ramsey’s reply to the tweet that started the whole thing off.

Configuring Emacs is more of a lifestyle choice than a task that one completes.

— Stephen A. Ramsey (@stephenaramsey) November 23, 2021

I usually express this by comparing my Emacs configuration to a Japanese garden: It’s a work that’s always in progress but never finished. The gardener spends his life improving the garden little by little and striving for a perfection that is never reached. So it is with our Emacs configurations: A neverending search for an ideal never achieved.

A couple of years ago I wrote an article about dealing with typos in your source code. Today I’ll follow up with a simple recipe to automate this spell-checking process using GitHub Actions (GHA).¹

Lately I’ve been adding the following GHA workflow to all of my OSS projects:

name: Spell Checking

on: [pull_request]

jobs:
  codespell:
    name: Check spelling with codespell
    runs-on: ubuntu-latest
    strategy:
      matrix:
        python-version: [3.8]
    steps:
      - uses: actions/checkout@v2
      - name: Set up Python $
        uses: actions/setup-python@v2
        with:
          python-version: $
      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          pip install codespell
          if [ -f requirements.txt ]; then pip install -r requirements.txt; fi
      - name: Check spelling with codespell
        run: codespell --ignore-words=codespell.txt || exit 1
  misspell:
    name: Check spelling with misspell
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Install
        run: wget -O - -q https://git.io/misspell | sh -s -- -b .
      - name: Misspell
        run: ./misspell -error

There’s nothing fancy here. We’re just installing a couple of popular spell-checkers for code and we run them on everything within the Git repository. If they discover any problems the build will fail.

Just save the code above under .github/workflows/spell_checking.yml and you’re good to go. The workflow will get triggered for each subsequent pull request.

A couple of things to note:

• This workflow uses both codespell and misspell. Using both might be an overkill for some of you. Personally, I like misspell more, as it’s super fast.
• It’s a good idea to run both tools locally first and address any existing typos.
• You may want to limit the checks only to files that were changed in the pull request.
• You may want to specify a locale for misspell if you want to enforce a specific flavor of English (e.g. misspell -locale US).
• This should probably be made a reusable workflow. I won’t be surprised if someone actually has created a public reusable workflow for spell-checking code already.

That’s all I have for you today. Big thanks to my fellow OSS hacker Koichi Ito, who came up with the idea of making spell-checking a CI step. In hindsight it seems like a very obvious thing to do, but it was always an afterthought for me. I’d be curious to hear how others are dealing with typos in their codebases.

When you edit org files, sometimes you want to emphasize words like code or verbatim.

By default, Doom Emacs shows the leading or trailing marker characters like = or ~. So the org file looks funny.

Naturally, you want to hide the these characters, like an org-link.

This SO answer provides a solution: Toggle on org-hide-emphasis-markers

Before:

After:

To further customize each emphasis face, you can tweak the org-emphasis-alist variable and pick or customize each face, like org-verbatim. Here is an example.

Automating the Repetetive while also Learning a Bit More about My Editor

In October I joined Forem as the lead engineer for the content experience team. I’ve been contributing to open source software for 9 years; Hello Samvera.org; I miss you but I promise I’m in a good place.

Coming from one open source community to another, I brought with me different workflows. I favor writing verbose commit messages. I like to use that as the text for my pull requests. The benefits are that commit messages travel with the code-base. I can use git annotate to help me understand the situation around a chunk of code.

But, in an open source community with over 600 contributors, the commit message as pull request strategy is inadequate. We could use git hooks to provide commit message templating, but that’s not enough for conversations around the pull request.

Forem provides a pull request template to guide contributors through all of the considerations that go into the pull request review and acceptance.

The template provides a nice pre-amble comment to help new contributors. Then provides clear sections and instructions for a contributor to fill out:

• What type of Pull Request
• Description
• Related Tasks & Documents
• QA Instructions, Screenshots, and Recordings
• Accessibility Concerns
• Added/updated Tests
• How will this change be communicated? (A Forem Core Team only section)
• Any post deployment tasks to complete
• A GIF that Expresses How You Feel About this Contribution

As a new contributor to Forem, I love this guidance. And as I began reviewing other pull requests, I appreciated the structure even more.

My Current Pull Request Workflow

When I’m working on the code, I continue to write verbose commit messages. Then, when I’m ready, I push up my branch and push the button to create a pull request for the branch.

By default, Github prepends the last commit message to the text of the pull request template. I focus my browser into that text area and use the editWithEmacs.spoon to copy that text and paste it into a new Emacs buffer on my machine.

In that Emacs buffer, I then go about editing the pull request text.

When I’m done, I type Ctrl+c then Ctrl+c (e.g., C-c C-c in Emacs parlance) to copy the text from my Emacs buffer and paste it back into the browser’s text area. Magit and Org Mode use that key combination for confirmation of commands.

And I submit my pull request.

Automating My Workflow

Once I started editing these pull requests in Emacs, I started to see the clean-up work that I was regularly doing before I started filling out the checkboxes. And because I was now in my text editor, I chose to write a script to do that clean-up.

Without reading the elisp code, it:

• Removes the comment preamble
• It adds the last commit message as the description
• It tidies up the comments of two sections

Below is the lisp code to do the tidying up:

(defun jnf/forem-tidy-pull-request ()
  "Perform some quick tidying of the Forem PR template."
  (interactive)
  ;; Start from the beginning.
  (beginning-of-buffer)

  ;; The text before the first HTML/Markdown
  ;; comments is the commit message.  Cut that
  ;; text...
  (search-forward "<!--")
  (kill-region 1 (- (point) 4))

  ;; ...and paste it inside the description
  ;; section.
  (replace-string
   "## Description\n\n"
   (concat "## Description\n\n"
           (format "%s" (car kill-ring))))

  ;; We've moved point (e.g., the cursor) so let's
  ;; jump back to the beginning of the buffer.
  (beginning-of-buffer)

  ;; Remove HTML/Markdown comments
  (replace-regexp
   "\\(\n\\)*<!--\\(.\\|\n\\)*-->\\(\n\\)*"
   "")

  ;; Clean out the comments for QA instructions;
  ;; I'll write them, but the notes are
  ;; unnecessary.
  (replace-regexp
   "QA Instructions, Screenshots, Recordings\\([^#]\\)*"
   "QA Instructions, Screenshots, Recordings\n\n")

  ;; Clean out accessibility concerns; I'll write
  ;; them, but the notes are unnecessary.
  (replace-regexp
   "UI accessibility concerns?\\([^#]\\)*"
   "UI accessibility concerns?\n\n"))

Then comes the keyboard bindings to make this easier.

When copying from browser to Emacs, the editWithEmacs.spoon toggles on the hammerspoon-edit-minor-mode for the buffer. See the code for those details. The following code adds a new key binding Ctrl+c then t to the keyboard mappings.

(define-key
  hammerspoon-edit-minor-map
  (kbd "C-c t")
  #'jnf/forem-tidy-pull-request)

Kind of nice. Load the content into an Emacs buffer, type Ctrl+c then t and I’m a few steps closer to completing my pull request.

What remains?

I wrote a script to build a pull request message from commit messages. Note, at my previous employer they chose to keep using—and keep choosing to use—the branch name master hence the code defaults to that.

I would like to better incorprate that conceptual script into my workflow.

And if I’m feeling up for the challenge, I’ll grab any Github links from the commit messages and add those to the related tasks and documents.

Conclusion

Since joining Forem, I’ve issued 32 pull requests. And as I started doing this task more, I started wondering, “How might I tweak my tooling to address some repetetive tasks?”

I let that question linger as I wrote several pull request messages in Emacs. And then, with a bit of time, I chose to spend a bit of time writing the above script. I don’t know how many pull requests I’ll need to write to “make up” for the time spent on the script.

But that is a lesser concern. I’m more concerned with getting comfortable understanding the interplay of the various systems I use and how I can mold them to assist in the tasks at hand.

When I start to create a pull request, I can quickly run the clean up task so that I can then focus on writing the pull request. In other words, I automated away a “distraction” so I could stay closer to the area of focus.

Lars Ingebrigtsen has an interesting post about proportional fonts in the Emacs mode line. His post shows the same mode line in both fixed and proportional fonts. There’s no arguing that the proportional fonts look better and that they allow for the display of more information on the mode line.

Still, the suggestion to move to proportional fonts is an old one and has always been controversial. There are some serious objections. For one, things like the point position are updated with every character typed and that can cause the mode line display to shift right or left.

Ingebrigtsen says that they’re running a month long test on Emacs Master in which proportional fonts on the mode line are enabled by default. They’ve installed a fix for the problems of things like the point position and the developers are hoping that that will address previous objections to using proportional fonts.

Regular readers know that I don’t care much about this sort of thing. All in all, I’m happy with a fixed width font mode line but I don’t find the idea of proportional fonts objectionable either. If you’re tracking Emacs Master, be sure to let the developers know what you think.

UPDATE [2021-11-26 Fri 13:15] Emacs 28 Master → Emacs Master.

This article is a quick follow-up on yesterday’s post on redoing complex commands. I’ve noticed today that the popular Emacs package consult offers a much more powerful version of the built-in repeat-complex-command command. The consult version is named consult-complex-command and has a couple of nice advantages:

• candidate filtering
• TAB-completion

Basically, it’s lot faster to find what you’re looking for. If you’re into consult I’d suggest just using its version in place of the built-in command:

(global-set-key [remap repeat-complex-command] #'consult-complex-command)

You can invoke consult-complex-command with C-x M-: or C-x ESC ESC.

That’s all I have for you today. The consult package is full of powerful versions of built-in Emacs commands, so you’ll do well to spend some time exploring it. I know I will!

Just a scant handful of decades after XEmacs introduced a mode line with proportional fonts, we’re thinking about doing the same in Emacs.

Here’s how the mode line looks (by default) in Emacs 28:

Here’s how we’re considering having it look (by default) in Emacs 29:

See? Huge difference. Huge.

The attractive thing about this change is that, well, it’s prettier, but it’s also more consistent with the other elements at the margins of the Emacs frame: The menus and the toolbar have used proportional fonts for a long time, so doing the same in the mode line might also be nice. And you can generally squeeze in more information when using proportional fonts, which is helpful if you’re jamming a lot of stuff into the mode line:

Changing this has been brought up a number of times over the years, but there’s been pushback because some of the elements in the mode line are pretty dynamic, and it’d suck if everything moved around. For instance, when displaying the column number in the mode line, it might be annoying to have the rest of the line shift to the left/right when moving the cursor around in the window.

So we’ve now added a new display spec (called ‘min-width’) today that you can slap around bits of text (and in the mode line) that ensures that the width never decreases beyond a certain point.

Perhaps that’ll make a difference in the level of resistance? I guess we’ll find out, because starting today, we’re doing a one month long test on “master”: This new mode line look is enabled by default now, and in a month we’ll evaluate based on feedback.

So give it a whirl for a few weeks, and vote on emacs-devel mailing list. (And report any glitches, of course. And suggestions for improvements are always welcome.)

I don’t know about you, but from time to time I definitely have the need to re-run some Emacs command that takes user input (e.g. query-replace). For the purpose of this article let’s call such commands “complex” commands. Obviously we can just invoke the same command, provide again the input (directly or using some parameter history if available), but it would be nice if there was a faster way to do this.

As it’s usually the case with Emacs, such a way already exists - the built-in command repeat-complex-command. By default it’s bound to both C-x M-: and C-x M-ESC.¹ When you invoke the command you’ll see in the minibuffer the last Emacs command you ran and you can use M-n and M-p to move forward and backward in the command history.

You’ll notice that the commands are listed as Emacs Lisp code that you can edit directly if needed. You’ll also notice there are no commands that don’t any parameters on the list. Imagine something like:

(describe-key '(("\272" . [134217786])))
(occur "emacs" nil)
(projectile-ag "emacs" nil)
(markdown-insert-gfm-code-block "emacs-lisp" nil)

This might also give you a hint as to why the keybinding C-x M-: was chosen - it’s pretty close to M-: (eval-expression), which allows you to run arbitrary Emacs Lisp code from the minibuffer.

When it comes to Emacs we’re all constantly learning. I didn’t know about this command until several days ago I saw it in a tweet shared by Mickey Petersen, a true Master of Emacs. Thanks for the tip, Mickey!

Recently I came across this tweet about Emacs and its users:

Some of the best programmers I know have been using Emacs for as long as I've known them.

Equally, almost all of them have been setting up their Emacs config for as long as I've known them.

— Sidu Ponnappa 💉💉 (@ponnappa) November 23, 2021

Funny and true at the same time! I casually retweeted it and I immediately forgot about it. A bit later, however, I was mentioned in one response to the tweet that really caught my attention:

Configuring Emacs is more of a lifestyle choice than a task that one completes.

– Stephen A. Ramsey

I think that perfectly captures the spirit of Emacs and the nature of its (most devoted) users. I’d even go a bit farther and make the claim that (using) Emacs is essentially a lifestyle (choice).

After all, none of us were forced to use Emacs. None of us were forced to dedicate years of our lives to building the perfect Emacs configuration. None of us were forced to preach the gospel of the Church of Emacs. We do it all, because in Emacs we find the creative outlet that we’ve been always looking for. We do it, because Emacs gives us the choices that others don’t. We do it, because being pragmatic all the time is boring.

For us Emacs is much more than a mere text editor - it’s part of who we are. Emacs is a lifestyle. Emacs is our lifestyle!

When clj-refactor 3.0 was released, I promised you that the release of CIDER 1.2 wasn’t far behind. However, an entire month has passed since then and CIDER 1.2 is still brewing. Turned out there was more work to be done than I expected, that’s why I decided to provide a short progress update.

Several things contributed to the delay. Here’s a brief rundown in no particular order:

• nREPL 0.9 was delayed a bit by some problems we’ve discovered with the new Unix socket transport. The problems have been addressed and I expect that we’ll finalize nREPL 0.9 in the next week or so.
• Due to the nREPL issues mentioned above, we still haven’t added support for the new Unix socket transport to CIDER.
• There’s some cleanup work that has to be done in Orchard with respect to switching from dynapath to enrich-classpath for automatically adding Java sources and Javadoc to the classpath. That cleanup is optional for this particular release, but I’d rather do it sooner rather than later.
• I want us to support properly nbb in CIDER 1.2. This requires some changes to the ClojureScript bootstrap logic in CIDER, as nbb is a native Node.js implementation that works differently from all the ClojureScript REPLs we’re currently supporting (notably you don’t need to evaluate any code in a Clojure REPL to “upgrade” it to a ClojureScript REPL).
• I still haven’t submitted CIDER and its dependencies to NonGNU ELPA, so that people would be able to install CIDER out-of-the-box on Emacs 28.
• I’ve been crazy busy at work, which limited the amount of time I could allocate to CIDER and friends.

In light of everything listed above, right now I’m aiming to release CIDER 1.2 around Christmas. Note that the current CIDER snapshot is in a pretty good shape overall and you can upgrade to it without any concerns about the stability issues.

If you want to know more about the current state of affairs, please check out this meta ticket, which tracks all the remaining work. As usual any help with the outstanding tasks will be greatly appreciated!

To wrap up on a positive note - in the mean time we released clj-refactor 3.1 and 3.2 with a bunch of small improvements! We might be moving a bit too slow at times, but we’re always moving forward!

It is on all of us to decide how it is that we are working with and using tech in 2021 as even the smallest decision has a cumulative effect. … Which ideology are we supporting through our software use/contributions and why?

After switching (think) to Minimal Mistakes I’ve been doing some small improvements to the site’s structure and content. I thought it might be a good idea to summarize them here:

• I’ve updated the About page. It now includes a lot more information about me and (think)’s background and mission.
• I’ve moved the contact information from the About page to a dedicated page.
• I’ve added a simple lunr-powered search. I should have done this a while ago, but Minimal Mistakes made this so easy that I finally had no excuse not to do it. It’s not as fancy as Algolia-powered search, but it mostly gets the job done.
• I’ve replaced the old custom Archive and Tags pages, with the versions of those pages provided by Minimal Mistakes. Now they look much better as a result.
• I’ve added dedicated Atom feeds for the main topics I’ve historically written about:
  • Ruby
  • Clojure
  • Emacs
  • Meta (I use this a replacement for “Misc”, so expect all sorts of disconnected articles here)
• I’ve added a table of contents to many of my longer articles (here’s an example
• I’ve been going over some of my old articles and I’ve fixed tags, broken links, typos, grammar and markup here and there.

I have to say that this has been a very fun process and Minimal Mistakes has been an absolute joy to use so far! Next step - finally learn how to use Jekyll’s collections and add something else besides articles to the site.

Doom Emacs has editor/fold module which makes folding code simple

Steps:

• Move cursor to the code block opening
• M-x +fold/toggle or C-c C-f C-f

Demo (folding a large hash in ruby):

I won’t be including all of the talks I will be watching here but those that are aligned with topics I cover on this blog. I tried to keep this short – !

• Upcoming events:
  • EmacsConf 2021: Schedule, & How to Watch and Participate (Reddit)
  • Emacs Berlin (virtual, in English) https://emacs-berlin.org/ Wed Nov 24 0930 Vancouver / 1130 Chicago / 1230 Toronto / 1730 GMT / 1830 Berlin / 2300 Kolkata – Thu Nov 25 0130 Singapore
  • EmacsConf https://emacsconf.org/2021 Sat Nov 27 0600 Vancouver / 0800 Chicago / 0900 Toronto / 1400 GMT / 1500 Berlin / 1930 Kolkata / 2200 Singapore
  • EmacsConf https://emacsconf.org/2021 Sun Nov 28 0600 Vancouver / 0800 Chicago / 0900 Toronto / 1400 GMT / 1500 Berlin / 1930 Kolkata / 2200
  • EmacsATX: TBD https://www.meetup.com/EmacsATX/events/281742622/ Wed Dec 1 1630 Vancouver / 1830 Chicago / 1930 Toronto – Thu Dec 2 0030 GMT / 0130 Berlin / 0600 Kolkata / 0830 Singapore
  • M-x Research (contact them for password): TBA https://m-x-research.github.io/ Fri Dec 3 0700 Vancouver / 0900 Chicago / 1000 Toronto / 1500 GMT / 1600 Berlin / 2030 Kolkata / 2300 Singapore
• Emacs configuration:
  • GNU Emacs #1 - Configurações básicas da interface (40:53)
  • teton: An opinionated set of emacs & zsh dotfiles for macOS that prioritizes simplicity and documentation
  • anonimno's Emacs Config
• Emacs Lisp:
  • Binary trees in #emacs-lisp (09:20)
  • Elisp/Emacs-Lisp (20:00)
• Appearance:
  • Two desktop clocks a lá Conky with Emacs (Reddit, also Reddit)
  • Protesilaos Stavrou: Modus themes 1.7.0 for GNU Emacs
• Navigation:
  • Emacs windmove integration with i3
  • Emacs Pane Focus Back 2021_11_18_09:19:28 (Reddit)
• Org Mode:
  • Emacs TIL: Anki <-> Org
  • Wrote a clockreport that groups by day and by project
  • trc-workgraph.el — Visualize org mode files as graphs
  • UOMF: Logging system error messages to my Emacs org-mode agenda (Reddit) - updated
  • taproot3: Taproot, the connected Zettlekastenish braindump of Emacs Org users Huxley, Albert, Zach, Houjun, Dylan, Peter, and David
• Completion:
  • Protesilaos Stavrou: Emacs: mct version 0.3.0
• Coding:
  • System Crafters Live! - Tools for Building a Lisp-Focused System (01:55:46)
  • Irreal: Git History for Selected Text
  • [New Package] Code Review from Emacs
  • Manuel Uberti: On Eglot and VC
  • Emacs Sign Git Commit In Magit 2021_11_21 07:17:00 (Reddit)
• Shell:
  • Have you created any eshell things that you keep to yourself? Here's mine
  • eshell-p10k: p10k theme for eshell
• Math:
  • Formula Editor in GNU Emacs (Reddit)
• Fun:
  • Emacs Is A Gaming Platform for Windows, Mac and Linux
• Community:
  • Weekly Tips, Tricks, &c. Thread
  • Why Emacs: Redux (Reddit, HN, Irreal)
  • Emacs in fifty keystrokes (and why some of you should just use Vim) (Reddit)
  • #Emacs manuals translation and #OmegaT
  • Gretzuni: EmacsConf2021: Emacs as design pattern learning
• Other:
  • Diffing directories content size
  • [New Package] Instant LaTeX preview & more web popup tooltip using popweb (Reddit)
  • Pdf Viewing Inside Emacs 2021_11_21_21:08:32
  • Emacs Insert Date Time 2021_11_22_08:06:40
  • Copying Media to Emacs by Lars Ingebrigtsen (Reddit)
  • How I, a Emacs User, turned my iPad Pro into my main computer (Reddit)
• Emacs development:
  • Make `xwidget-display-event' a special event as well
  • Add support for the Haiku operating system and its window system
  • Add support for event processing via XInput 2
  • Allow terminating page loading operations in webkit xwidgets
  • Make xwidget-webkit default to not storing cookies
  • Fix documentation of last commit
  • Allow controlling where xwidget-webkit stores cookies
  • Add `xwidget-webkit-estimated-load-progress'
  • Signal an error for duplicated ERT tests (bug#51941)
  • Add command to browse xwidget history
  • New X resource to control the border thickness of menus
  • Make results details in ert-run-tests-batch configurable
  • Add new 'keymap-*' functions
  • Allow removing keymap definitions
  • Support abbreviating home directory of Tramp filenames
• New packages:
  • kind-icon: Completion kind icons
  • cape: Completion At Point Extensions
  • code-review: Perform code review from Github
  • ruby-json-to-hash: Convert JSON to Hash and play with the keys

Links from reddit.com/r/emacs, r/orgmode, r/spacemacs, r/planetemacs, Hacker News, planet.emacslife.com, YouTube, the Emacs NEWS file, Emacs Calendar and emacs-devel.

I will be giving a talk at this year’s EmacsConf2021 that was an indirect exercise in considering the new wave of programming that is upon us.

I haven’t talked about Common-Lisp on Irreal for a long time. That’s mostly because the majority of my recent Lisp programming has been in Elisp but I still love Common-Lisp and Scheme and am always happy when I find an interesting article about them. I particularly like articles that show how Lisp is being used to solve real world problems.

For a long time, the canonical example of this has been ITA Software, but there are others and azzamsa and his collaborators have a list. When he saw the list, Alex Nygren told them about his company Kina Knowledge that makes extensive use of Common-Lisp and its homegrown lisp, DLisp, that compiles to Javascript. That led to a nice blog post by vindarel that describes the Kina system and how Lisp fits into it.

You should read the post for the details but the TL;DR is that their technology stack is made up of Ruby/Rails, Javascript, Common-Lisp, and DLisp. Most of their front end is written in DLisp and is available to the end user. The back end is Common-Lisp that does much of the heavy lifting. And, as a bonus, Nygren uses Emacs for his Lisp coding and documentation. It makes sense; if you’re a Lisper, Emacs is a natural fit.

The post is well worth a read if you’re interested in how Lisp is being used today. There aren’t, I’m sure, enough Lisp jobs for everyone who wants one but they aren’t non-existent either. Paul Graham famously described Lisp as their secret weapon at Viaweb and related how they tried to prevent their competitors from finding out they were using it. Perhaps more companies will get the message and the number of Lisp jobs will increase.

I have been pretty busy since my last update here, but that does not mean I haven’t had the time to explore a couple of things for my everyday Emacs usage.

Lately I had to deal with some Java and some JavaScript. No fancy libraries on top of them, no languages built upon them, just plain, old Java and JavaScript. I took that as a chance to familiarize myself with LSP and especially with Eglot, one of the two (to my knowledge) packages that add LSP support to Emacs. Why Eglot and not lsp-mode? Simple: I like how Eglot leverages project.el and Flymake, tools I heavily rely on, and I also like how quickly it enabled me to type Java and JavaScript code.

(add-hook 'java-mode-hook #'eglot-ensure)
(add-hook 'js-mode-hook #'eglot-ensure)

Neat, huh?

Eglot works well with Company, Xref, and ElDoc, so coding in Java finally makes sense in Emacs. Granted, I haven’t used it on a big project and I am sure the likes of IntelliJ IDEA and Eclipse do wonders, but none of them has the editing capabilities or the openness to infinite customization that Emacs offers.

Another tool that entered my day-to-day computing is the built-in version-control system, or VC for short. My love for Magit is well-known, but on my way to a vanilla Emacs appreciation I thought I could give VC a try. It turns out most of the things I need to do with my Git-versioned projects can be done from vc-dir. This means that instead of C-x g for magit-status I have been using C-x p v for project-vc-dir. When it’s time to get my hands dirty with some advanced Git-fu, Magit is always next to me.

One thing should be obvious here: Magit is more powerful and feature rich than the built-in VC, so I do not intend to drop Magit as quickly I dropped Projectile and Flycheck. Why don’t I just use Magit, then, you ask. For the same reason I tried Eglot instead of installing Eclipse, I’d reply. Curiosity will not kill any cat in my house.

Here’s a nice tip for finding all the commits related to some selected text in Magit:

In #magit of #emacs, M-x magit-log-buffer-file with a region selected, this will show the region related commits only. https://t.co/bnWwhrGKUw #git

— Jumpei KAWAMI (@junkw) November 16, 2021

I haven’t tried this in anger but it seems as if it could be useful when trying to figure out how a bit of code has changed over time.

This post is about how to sync notes between Org and Anki manually.

Background: In an effort to consolidate all my notes into *.org files, I need to deal with the old Anki decks.

Luckily, Anki supports exporting notes into plaintext files.

If you want to import the same file, you need an add-on to generate the Node ID for each note.

Make sure Node ID field is added in the deck setup:

Sample exported txt file:

9162f8c6-4942-11ec-8423-acde48001122 front 1 updated back 1 updated 98699bac-4942-11ec-8423-acde48001122 front 2 updated back 2 updated

With this plaintext file, you can use whatever you are comfortable to convert them into your org format.

For example, if you are using Org-Roam, the first note can be converted to:

:PROPERTIES:
:ID:       9162f8c6-4942-11ec-8423-acde48001122
:END:
#+title: front 1 updated
* Front
front 1 updated
* Back
back 1 updated

After you are done editing on org, it is a matter of converting them back to the plaintext files and importing them into Anki again:

In this way, you can manually sync notes between Org and Anki.

Below are the release notes. If you have no idea what mct is, it is a very thin layer of interactivity on top of the default completion user interface. Watch the video demo of the initial release.

Version 0.3.0 on 2021-11-19

This entry describes the changes to Minibuffer and Completions in Tandem (mct) since the release of version 0.2.0 on 2021-11-12. There have been more than 40 commits since then. For further details, please consult the manual online: https://protesilaos.com/emacs/mct. Or evaluate the following expression if you have the mct package installed:

(info "(mct) Top")

As this release is a continuation of version 0.2.0, the changelog for that version is also provided below (I released version 0.2.0 earlier than anticipated so that users could get a stable package on GNU ELPA). Here is a brief description of what has been achieved in 0.3.0.

MCT on Emacs 27

• MCT now works on Emacs 27. This was not possible in the past because mct-mode was originally designed to operate with the one-column style of the completions-format, which was added in Emacs 28. To make everything behave intuitively, several parts of the code had to be abstracted and refactored (the changelog of version 0.2.0 (further below) covers everything not mentioned here).

• The scenaria where the functionality was thoroughly tested involve all the available formats and cover commands that fulfil the following criteria:
  • Plain completion candidates, as in switch-to-buffer.
  • Dynamic completion like that of find-file.
  • Annotated candidates, as seen in describe-symbol for versions of Emacs 28 or higher.
  • Commands where candidates are grouped by heading, as done by various extensions of the consult package, such as consult-imenu.
  • Commands where no completion category is associated with them.

• The only change which is visible to the user is the implementation of a bespoke overlay to highlight the current candidate. In previous versions, this was provided by the built-in hl-line-mode, though that does not work as intended with either the vertical or horizontal layouts of the completions-format as it covers the whole line instead of the candidate at point.

• The highlight extends to the edge of the window when the one-column format is used for the completions-format (Emacs 28 or higher). In the other views it stretches from the beginning to the end of the completion candidate.

• Thanks to Case Duckworth for the initial request and subsequent testing in issue 1: https://gitlab.com/protesilaos/mct/-/issues/1.

Miscellaneous changes

• There is a new command that is active in the minibuffer which allows to complete and exit immediately: C-RET (mct-complete-and-exit). This economises on key presses when all the user wants is to select the top-most candidate (or last highlighted one) without first switching to the Completions’ buffer and then confirming it from there (RET in the *Completions* buffer completes and exits directly).
  • Thanks to José Antonio Ortega Ruiz for the contribution in merge requests 3 and 4 as discussed in issue 8:
    • https://gitlab.com/protesilaos/mct/-/merge_requests/3
    • https://gitlab.com/protesilaos/mct/-/merge_requests/4
    • https://gitlab.com/protesilaos/mct/-/issues/8
  • Note that “exit” in this context denotes the process of terminating the session while accepting the current input. The term used to quit without accepting the input is “abort”.

• The mct-mode does not get activated in contexts where (i) the minibuffer is involved but (ii) no completion takes place. For example, the eval-expression command (bound to M-: by default).

• mct-mode no longer remaps the faces of the display-line-numbers-mode. This was a useful experiment from the early days of the code base, although it is bad practice for a user-facing package.

• Various tweaks and refinements to the manual.

• Retroactive introduction of a CHANGELOG.org file and coverage of all noteworthy changes hitherto.

0.2.0 on 2021-11-12

This entry describes the changes to Minibuffer and Completions in Tandem (mct) since the release of version 0.1.0 on 2021-10-22. There have been 70 commits since then. For further details, please consult the manual online: https://protesilaos.com/emacs/mct. Or evaluate the following expression if you have the mct package installed:

(info "(mct) Top")

Packaged version of MCT

mct is now available on the official GNU ELPA archive for users of Emacs version 28 or higher. One can install the package without any further configuration. The following commands shall suffice:

M-x package-refresh-contents
M-x package-install RET mct

Changes to the format and placement of the Completions

• The user option mct-live-completion controls how and when the Completions’ buffer should be placed in a window and be updated live in response to user feedback. Copying from the doc string:

  mct-live-completion is a variable defined in ‘mct.el’.

  Its value is t

  Control auto-display and live-update of Completions’ buffer.

  When nil, the user has to manually request completions, using the regular activating commands. The Completions’ buffer is never updated live to match user input. Updating has to be handled manually. This is like the out-of-the-box minibuffer completion experience.

  When set to the value visible, the Completions’ buffer is live updated only if it is visible. The actual display of the completions is still handled manually. For this reason, the visible style does not read the mct-minimum-input, meaning that it will always try to live update the visible completions, regardless of input length.

  When non-nil (the default), the Completions’ buffer is automatically displayed once the mct-minimum-input is met and is hidden if the input drops below that threshold. While visible, the buffer is updated live to match the user input.

  Note that every function in the mct-completion-passlist ignores this option altogether. This means that every such command will always show the Completions’ buffer automatically and will always update its contents live. Same principle for every function declared in the mct-completion-blocklist, which will always disable both the automatic display and live updating of the Completions’ buffer.

  • Thanks to Jonathan Irving for the feedback in issue 4: https://gitlab.com/protesilaos/mct/-/issues/4.
• As with all buffers, the placement of the *Completions* can be controlled with the display-buffer machinery. The default is to show the completions at the bottom of the frame, though users can easily move it to, say, the left side window. The doc string of the user option mct-display-buffer-action explains how to do so.

  • Thanks to Philip Kaludercic for the initial implementation in commit 436b24e (was sent via email as a patch).

  • Thanks to Kostadin Ninev for reporting a bug where the Completions’ buffer would proliferate during completion: https://gitlab.com/protesilaos/mct/-/issues/3. It was fixed by Philip Kaludercic in commit 51c1e17.

• MCT now supports all the available styles of the completions-format, whereas the original design was only meant to work with the value one-column, which was introduced in Emacs 28. The user option is mct-completions-format. If that variable is set with setq, the mct-mode has to be restarted manually for changes to take effect (setting the variable through customize-set-variable (and related) handles the mode reloading automatically).

  • Thanks to Philip Kaludercic for the patch in commit b392b0b.

  • Several changes were then made to ensure that the cyclic motions that move between the *Completions* and the minibuffer work intuitively in a grid view. In short: C-n, C-p or the down/up arrow keys, perform a vertical motion, while the left/right arrow keys move laterally. Prior to those changes, C-n or down arrow as well as C-p or up arrow, would perform a lateral motion as that is internally the meaning of the next/previous completion candidate.

  • The command mct-choose-completion-number was updated to throw a user error when a grid view is active. That is because it is designed to jump to a given line number, which only works as intended when there is only one candidate per line. (Perhaps a future release should overlay characters over candidates in the grid view to select them directly.)

• The mct-mode no longer sets the completions-detailed variable. That is a matter of user preference. It is not integral to the functionality of MCT.

Group motions

• Emacs 28 provides infrastructure for commands to group candidates based on their contents. These groups can have their own heading in the Completions’ buffer, as well as a separator. Overall, it makes things look more organised. The commands mct-next-completion-group and mct-previous-completion-group move between those headings. While in the *Completions* buffer, they are bound to M-n and M-p, respectively. Thanks to James Norman Vladimir Cash for the contribution in merge request 2: https://gitlab.com/protesilaos/mct/-/merge_requests/2.

Miscellaneous changes

• The TAB key in the Completions’ buffer never exits the minibuffer (the command is mct-choose-completion-no-exit). Instead, it expands the current candidate in the minibuffer and switches focus to it. Before, this behaviour would only happen in find-file and related prompts, but consistency/predictability is better.

  [ By contrast, RET (mct-choose-completion-exit) in the Completions buffer always exits with the candidate at point. ]

  Note that in this context “exit” means to close the session and accept the current input.

• There is a new heuristic to deal with commands that let bind the crm-separator (e.g. org-set-tags-command sets the separator to :). This is used to make M-RET (mct-choose-completion-dwim) in the Completions buffer work in all completing-read-multiple contexts. Thanks to James Norman Vladimir Cash for contributing the heuristic in merge request 1: https://gitlab.com/protesilaos/mct/-/merge_requests/1.

• The aforementioned M-RET command used to have the same effect as RET when not in a completing-read-multiple prompt (“CRM prompt”). This has now been revised to behave like TAB instead (as described further above), which is consistent with the ordinary behaviour of M-RET in CRM prompts where it appends the candidate at point to the minibuffer, without exiting.

• The check for display-line-numbers-mode tests whether it is bound, thus avoiding possible errors. Thanks to Philip Kaludercic for the patch in commit 6bd2457.

• Made several improvements to doc strings and various snippets of code.

Updates to the manual

• All of the aforementioned were documented, where appropriate.
• A Makefile is now on offer, which is used to generate the mct.info and mct.texi files. Thanks to Philip Kaludercic for the patch in commit 295bac0.
• A sample setup is available for mct as well as several built-in options pertaining to the minibuffer.
• There are sections about third-party extensions as well as one that describes alternatives to MCT. Thanks to Manuel Uberti for the feedback in issue 5: https://gitlab.com/protesilaos/mct/-/issues/5.
• The “Acknowledgements” section includes the names of people who have contributed to the project in one way or another (code, ideas, user feedback, …).

Ten years ago, Bozhidar Batsov wrote a post entitled Why Emacs. It was a short essay on why he used Emacs, what was good about it, and what its shortcomings were. Ten years later, Batsov, like most of us, is a different person doing a different job.

Back then he was a programmer, mostly concerned with writing code but also writing a blog, (think), that he also wrote in Emacs so he could be said to be using Emacs for most of his text editing needs. These days he’s moved into management and no longer spends much time coding except for his OSS projects and the majority of his prose is written in Slack and Google Docs.

Still, Batsov continues to love Emacs and be one of the most prominant evangelists for it. He’s just written a retrospective on his post, Why Emacs: Redux. A lot of things haven’t changed: Emacs (and Vim) are still the premier way of editing text and Emacs’ extensibility is still unrivaled and the thing that sets it apart.

On the other hand, Emacs has not stood still. It has more packages than ever, it has rudimentary multithreading, a builtin JSON parser, good support for LSP, and, of course, native compilation. Emacs is definitely not standing still.

All of that is true but for me the real virtue of Emacs is power. The power to efficiently edit text, the power to extend it in virtually any direction I want, and the power to make it a Lisp-Machine-like operating environment.

Take a look at both posts. They’re interesting and a reminder of why we love Emacs so much.

I created Meta Redux a little over 3 years ago with the goal to start clean and write on topics that were meaningful to me. Today I want to examine how well did I do so far, therefore the extra meta title. And yeah, I’m well aware that I have some infatuation with the word “redux” - perhaps I just like revisiting things too much.

If you don’t remember the Meta Redux backstory, I’ll summarize it here quickly. Basically I had an older blog, that had went dormant around 2015 due to my frustration with Octopress, the tool I used to publish the blog. On top of this, as my original blog was my first attempt to write, I didn’t do well there. I wrote a lot of crappy articles early on, because I neither had anything interesting to share, nor was a skilled writer. I was somewhat embarrassed by this mess and I wanted to distance myself from it and get a fresh start. Also, I thought that starting a new blog would be easier than dealing with a migration away from Octopress. The idea to have a blog with a “cool/original” name was also appealing to me - after all most people never manage to remember my last name (Batsov, frequently misspelled as Bastov). That’s how Meta Redux was born on Oct 13th, 2018, my 34th birthday.¹

In the next 3 years I wrote over a hundred article at Meta Redux, which is quite the achievement given that in the previous 3 years I had written a grand total of 3 articles. What’s even better is that I was really happy with the quality of my work. It’s not like a wrote some Peter Norvig-level work of art, but at least it pleased me. Objective achieved!

Still, I had this lingering feeling that I cheated a bit, by starting a new blog. After all, everything I’ve written in the past is still (a reflection/snapshot of) me, regardless of how I feel about it today. I also wanted a clearer focus for Meta Redux, despite its deliberately unfocused name. As I’m writing a lot here about programming and my OSS work, I felt that other topics I’d occasionally write on didn’t quite fit in (e.g. tutorials and musings on hardware and operating systems). Still, such topics have some value to me and potentially to some of my readers. So what do about them?

In the end of the day I’ve decided to revive “(think)”² and use it to complement the topics I cover here. Basically, going forward I’ll limit myself here to programming (mostly Ruby and Clojure these days) and my OSS work (e.g. CIDER, RuboCop, etc), and everything else will go to (think). I’ve also removed some duplicated pages from Meta Redux (e.g. information about my talks and projects) and just redirected it to (think), for the sake of simplicity. This content originated there and I feel this is its true home.

The two blogs will also retain their different visual styles - I’ve vowed to keep Meta Redux as simple as possible, and to focus solely on the content here. With (think) I’ve taken some artistic liberties and I adopted a “more modern” theme, that seemed better suited for a person site that also doubles as a blog.³

I hope all this makes some sense. In hindsight probably it was a mistake to create a second blog in the first place, but I’m glad I did it. An experience you learn from is an experience worth having. Once again I was reminded that “less is more”.

I just released version 1.7.0 of the Modus themes. The release notes are reproduced below. For any questions pertaining to this publication, feel welcome to contact me.

I will now prepare the patch for the master branch on emacs.git (currently this corresponds to Emacs version 29). The modus-themes package in GNU ELPA fetches its contents from emacs.git, so expect an update to trickle down shortly after my patch is merged.

Modus themes version 1.7.0

By Protesilaos Stavrou info@protesilaos.com on 2021-11-18

The present entry records the changes made to the project since the release of version 1.6.0 on 2021-09-29. There have been more than 60 commits since then.

Every modification pertaining to colour combinations referenced herein is implemented in accordance with the primary accessibility objective of the themes for a minimum contrast ratio of 7:1 between background and foreground values in their given combination (the WCAG AAA standard). Edits also account for colour-coding that is optimised for the needs of users with red-green colour deficiency (deuteranopia).

To access the URL of the manual visit this web page: https://protesilaos.com/emacs/modus-themes. Or read it from Emacs by evaluating this form:

(info "(modus-themes) Top")

The themes are built into Emacs version 28 (next stable release), and are available on GNU ELPA as well as other archives. This release is the first one that is included with Emacs 29, or else the master branch in emacs.git.

Customisation options

• The modus-themes-no-mixed-fonts has been deprecated and replaced by the modus-themes-mixed-fonts. This is a breaking change for users who want to use “mixed fonts”: they must set the new variable to non-nil.

  As the name implies, the new variable changes the meaning of the feature to make it opt-in by default. This is consistent with the principle of least surprise, as users may not know why some fonts look different than others in certain cases.

  Thanks to Christian Tietze for clarifying the doc string of this new user option in merge request 51: https://gitlab.com/protesilaos/modus-themes/-/merge_requests/51.

  For context, “mixed fonts” refers to a design where spacing-sensitive constructs, such as code blocks and Org tables, inherit from the fixed-pitch face to remain monospaced (and properly aligned) at all times. Depending on the user’s configurations, the fixed-pitch face may not use the typeface that the user expects.

  The manual provides information on how to set the desired fonts by editing the default, fixed-pitch, and variable-pitch faces.

• The new modus-themes-mode-line-padding can be used to control the apparent padding of the mode line when the user option modus-themes-mode-line includes the padded property. The padding must be a positive integer (otherwise the code would be needlessly complex to guard against values that make the mode line look awkward, like anything lower than -3 or maybe even -2).

  Thanks to Guilherme Semente and Manuel Uberti for the feedback in issue 245: https://gitlab.com/protesilaos/modus-themes/-/issues/245.

  Note that the out-of-the-box style of the themes has a padding of 1 (technically a :line-width of 1 for the :box attribute), whereas the default style of Emacs has it at -1. This is a design choice to avoid an overlap between the outer boundaries of a font’s glyphs and the borders of the mode line, when using certain common typefaces at various point sizes. Such an overlap can hinder readability.

  The manual contains a new Do-It-Yourself (DIY) section with detailed code samples on how to apply a negative value.

• The new modus-themes-intense-markup option can be set to non-nil to make constructs such as inline code and verbatim text more colourful. This has a general utility, though its consideration was prompted by a phenomenon reported by Stefan Kangas in issue 238 where the overlay of the hl-line-face overrides the subtle background these constructs use and can thus make them virtually indistinguishable from ordinary text: https://gitlab.com/protesilaos/modus-themes/-/issues/238.

  Such is the standard behaviour of hl-line-mode and there is nothing a theme can (or rather “should”) do about it. Thanks to Stefan Kangas for the feedback.

• The modus-themes-headings option can now accept and apply an exact font weight such as semibold or light. (The list of available weights is the value of the modus-themes--heading-weights internal variable.) This supersedes the now-deprecated no-bold property: no-bold is henceforth understood as the presence of a regular weight.

  Recall that this user option is an alist and can be used to target heading levels individually, which further reinforces the utility of this new property.

  Thanks to Christian Tietze for suggesting this idea in issue 248: https://gitlab.com/protesilaos/modus-themes/-/issues/248. And thanks to Daniel Mendler for refining its implementation in commit 54bfd62, which was sent as a patch file (yes, we accept those and I actually prefer them over a web app’s UI).

• The modus-themes-org-agenda has seen improvements to its event key (this is an alist that has multiple keys). It now accepts a varied property which differentiates between (i) plain timestamp entries and (ii) entries that are generated from either the diary or a symbolic expression. The varied property combines with the other available properties to particularise their effects. Consult the doc string or the manual for the technicalities.

  Thanks to Gustavo Barros for the detailed commentary in issue 241: https://gitlab.com/protesilaos/modus-themes/-/issues/241.

• The modus-themes-lang-checkers now accepts a faint property. This has the effect of toning down the colours in use. By default, the only colour is that of the underline, though more can be added by combining the properties accepted by this user option. Consult its doc string or the manual for further details.

  Thanks to Morgan Smith for suggesting the idea in issue 239: https://gitlab.com/protesilaos/modus-themes/-/issues/239.

Add support for new packages or face groups

• company-tooltip-deprecated face. Thanks to Roman Rudakov for the feedback in issue 247: https://gitlab.com/protesilaos/modus-themes/-/issues/247.

• corfu-default face. Thanks to Daniel Mendler (Corfu’s developer) for the feedback in issue 254: https://gitlab.com/protesilaos/modus-themes/-/issues/254.

• image-dired package (Emacs 29). Thanks to Stefan Kangas for making it happen in emacs.git and for the feedback in issue 250: https://gitlab.com/protesilaos/modus-themes/-/issues/250.

• nano-modeline package.

• vertico-quick package. Thanks to Nicolas De Jaeghere for the contribution in merge request 48: https://gitlab.com/protesilaos/modus-themes/-/merge_requests/51.

Changes to existing faces or face groups

• Added support for the new Org agenda faces that improve the contextuality of various views. We implemented those upstream for Org version 9.5 in close cooperation with Gustavo Barros. Thanks to Gustavo for the detailed feedback in issue 241: https://gitlab.com/protesilaos/modus-themes/-/issues/241. The thread about the patch upstream: https://list.orgmode.org/87lf7q7gpq.fsf@protesilaos.com/

• Refined Org agenda date faces in the interest of consistency and in accordance with the aforementioned change. Thanks again to Gustavo Barros for the discussion in issue 241.

• Applied the shadow face more consistently across all contexts where only a subtle foreground value is expected. This design choice makes it possible for users to manually edit the foreground colour of shadow to something even more subtle than the fg-alt palette variable we use, which maps to a gray colour (e.g. they could use “gray50”).

• Implemented a subtle background colour to the widget-inactive face. This makes it easier to discern inactive buttons, checkboxes, and the like, in contexts such as the Customize User Interface. Thanks to Stefan Kangas for the feedback in issue 242: https://gitlab.com/protesilaos/modus-themes/-/issues/242.

• Tweaked file-name-shadow to also use italics (inherit from the italic face) in order to be more easy to distinguish it from ordinary text in the minibuffer.

  Recall that the manual documents the meaning of inheriting from the bold and italic faces instead of hardcoding a bold weight and an italic slant, respectively. In short: users can change the weight to what they want (e.g. semibold) and/or use distinct font families.

• Amplified the style of Version Control (VC) warnings and errors to let them draw more attention to themselves (because these indicators need to be acted upon).

• Recoloured the custom-group-tag face to make it fit better in its context and be consistent with the rest of the themes’ established patterns.

• Made marks for selection in Dired, Ibuffer, and related, conform with the modus-themes-success-deuteranopia option. This means that they use blue colours when the option is non-nil, instead of their default shades of green.

• Adjusted the box width of key bindings for Emacs 28 or higher. They should no longer cause any alignment issues. This style is now used throughout the themes, including in transient views (e.g. Magit) which were the exception before. Thanks to Manuel Uberti and Kevin Fleming for the feedback in issue 232: https://gitlab.com/protesilaos/modus-themes/-/issues/232.

Miscellaneous

• Wrote a brief description of every user option in the manual. Also covered its type, as in boolean, alist, et cetera.

• Corrected the mode line border width for one combination of properties in the modus-themes-mode-line option. This should now have the same height as all others:

  (setq modus-themes-mode-line '(accented borderless))
  

• Ensured that mode line attributes would not be set to nil, but kept at an unspecified value instead, where relevant. This avoids problems with [faulty] code that unconditionally depends on something that does not exist, as in the following while :box is nil:

  (face-attribute 'mode-line :box)
  

• Expanded, reworded, or otherwise improved the manual, based on the aforementioned.

Thanks once again to everyone involved!

For us Emacers, one of the longstanding shortcomings of iOS and, to a lesser extent, the Android ecosystem is the lack of an Emacs app. There are several Org-mode centered apps that allow you to perform various Org functions on your phone and sync the results with your computer through the cloud.

Álvaro Ramírez has another offering in this space. His Plain Org app provides a nice interface to Org’s task lists on your iPhone. Take a look at his post to see some animated Gifs of the app in action.

Until we finally get a native Emacs on iOS, apps like Plain Org will get us by. In the mean time, having a decent Org app is a boon. Most of what I want to do on my phone that involves Emacs involves some sort of Org file so having a good Org implementation that syncs back to my computer’s Org file is great.

redux
adjective

1. brought back; resurgent:
   the Victorian era redux.

A decade ago, I wrote an article titled Why Emacs?. I came across the article a few days ago and I felt that given its “anniversary” it’d be nice to revisit it.

2011 was an interesting year for me. It was the year in which I adopted Jekyll for this blog, which resulted in my most productive year in terms of articles I wrote. It was also the year which marked the birth of my first OSS projects - Projectile and Emacs Prelude. It was also the final year of my career as an (extra)ordinary programmer.¹ Emacs was a huge part of my life back then, and the “Why Emacs?” article was an attempt to share my passion for it with the world.

Fast-forward to the future and my life is very different today. The only programming I do these days is on my OSS projects, but I happen to have a lot of those. On the job most of the typing I do happens in Slack and Google Docs. My views on programming are very different from what they were back in 2011. One thing hasn’t changed though - I still love Emacs and I’m quite passionate about it.

I still write short articles about Emacs over at https://emacsredux.com. I still try different Emacs packages from time to time, and try to improve my workflow and my configuration. As I got older I developed a lot of appreciation for the “less is more” mindset and I’m using significantly fewer Emacs packages than before. In particular I stopped using Emacs for things like email, rss, chat, twitter, etc. I’m digressing…

My main aim today is to share how I’d make the case for Emacs today. You’ll notice that in the original article I spent a lot of time focusing on technicalities:

• editing experience
• overall feature set (mostly how Emacs compares to popular IDEs)
• resource utilization

They are important, of course, but they are not the most important thing.

I also made some wild claim that using IDEs impairs your thinking. Clearly I was around peak Emacs zealotry back then! Today we have even more IDE features in Emacs and I think that’s a good thing. In the end of the day Emacs has never been about enforcing one particular workflow - quite the contrary. Emacs is all about giving you choices!

Lisp isn’t a language, it’s a building material.

– Ward Cunningham

Emacs is not really an editor either! I believe that Emacs is the ultimate editor building material. The out-of-the-box experience is kind of basic and somewhat weird, but I don’t think that anyone should be using Emacs like this. You take this simple foundation, you shape and mold it to your taste and preferences and you end up with the best possible editor for you and you alone. That’s the reason why you should consider using Emacs.

Of course, one can make pretty much the same argument for our arch rival vim, and perhaps even for the modern king of editors VS Code. I’ve always liked vim and can’t say anything bad about it, other than I still don’t like Vimscript. For me, personally, the ability to extend Emacs easily with Emacs Lisp remains its number one advantage over vim.² There’s also the fact that you can re-create much of the vim experience with Emacs, but you’ll be hard pressed to re-create the Emacs experience in vim.

For all the good things that VS Code has brought to the table (e.g. LSP), I’m still somewhat skeptical about it in the long run. I don’t like open-source projects that are de-facto owned by one company. There’s always the conflict of interest between the company’s agenda and the needs of its users, and we know that the interests of the company usually come first.

I’ve also seen plenty of new editors and IDEs rise and fall in the past 20 years - Komodo, TextMate, Sublime Text, Atom, Eclipse, etc. Emacs and vim are the only editors that stood the test of time, and I have a feeling they will be with us for decades to come. This means that an investment in them will be likely paying you dividends much longer than an investment in a newer editor or IDE.

I’ll not go into details about the level of customization one can achieve in Emacs, as there are endless possibilities at every conceivable level. Besides thousands of third-party packages and the numerous configuration options (defcustoms) for anything and everything, every long-time Emacs user would have a bunch of custom Emacs commands that are unique to their use-cases and their way of working. The various Emacs distributions that exist today give you a different starting point on which to build upon. I like to think of them as different flavors of building materials, or foundations if you will. Spacemacs, one of the most popular Emacs distributions, has famously proven that you can build a rather faithful version of vim with Emacs.

On a more practical note I’ll also mention that Emacs has improved a lot since the time of my original article. Here are a few highlights:

• Today we have more great Emacs packages than ever. I blame the rise of GitHub and MELPA for that. The old maxim “Emacs has a mode for it!” is truer than ever.
• Emacs’s internal APIs are much more powerful than before. One can see that Clojure certainly influenced a few of them (e.g. if-let, thread-first, seq.el, map.el, etc).
• Emacs now supports a limited form of concurrency (introduced in Emacs 26).
• Emacs 27 started shipping a built-in JSON parser.
• Emacs has good support for LSP, which allows us to harvest the efforts of a lot of people for free. The gap between Emacs and VS Code and IDEs is a lot narrower than it used to be.
• Emacs 28 will bring massive performance gains with native compilation.
• Emacs has fantastic support for programming in Clojure.³ I think the popularity of Clojure and the fact that Emacs was the only editor to support it well early on gave Emacs a massive boost around the time of my original article.
• Emacs 29 will bring us proper support for emojis!

And that’s only the tip of the iceberg. Emacs is definitely not standing still and both the core and the third-party package ecosystem are constantly evolving and getting better. It’s safe to say that Emacs is no sinking ship, regardless of its modest usage compared to the likes of vim and VS Code.

So, why should you try Emacs in 2021?

• You’re a curious person and a constant tinkerer who likes playing with vintage software. You happen to have a lot of extra time at home on your hands because of the pandemic and you want to make the best of it.
• You want to experience life outside the mainstream.
• You’ve always wanted to learn a bit of Lisp.
• You want to build an editor that’s uniquely tailored to your needs and preferences.

Beware - Emacs is highly addictive and it might easily consume years of your life! I guess I’ve spent just as much time on Emacs projects as I did on refining my Emacs configuration.

So, we’re almost at the end. There’s just one more thing to do at this point - repeat after me the following chant⁴ 3 times:

Emacs is power!

Emacs is magic!

Emacs is fun!

Emacs is forever!

You’re now ready to begin your life-long journey to Emacs mastery. Meta-x forever! In parentheses we trust!

P.S. I’m including here the discussion threads for the article on:

• Reddit
• Lobsters
• HackerNews

Marcin Borkowski (mbork) has a short post on how to make y-or-n-p return t when the user types Return. Check his post for the details but the TL;DR is that he temporarily extends the y-or-n-p keymap to have Return return as if y had been pressed.

It’s a fairly unique requirement but his approach works for other use cases where we want to add or change a key to an existing keymap. If you have such a need, take a look at mbork’s post.

As an aside, I should mention that mbork’s new book is finished and available. I read a draft of his early chapters and thought it was well done. Take a look if you’re interested in Emacs books.

Let’s talk a bit about .net. No, not Microsoft’s .NET, but the other .net - one of the original top-level internet domains. Given how popular .com has become, I find it really strange that .net failed to reach such prominence. Even .org is more popular than .net!

That’s quite disappointing, as I think that historically .net was the best domain for personal sites, for various reasons:

• .com used to stand for “commerce”, so it’s a bit weird to be using such a domain for a personal site
• .org used to stand for a (non-profit) organization, so it’s extra weird to use such a domain for a personal site
• .net stands for “network”, which for personal sites I always interpreted as “my place on the (Inter)net”
• a lot of good names are still available for .net (compared to .com at least), as the domain is not super popular

Of course, today we have a lot more top-level domain options to choose from:

• .info, the first additional domain, that never took off
• a ton of country domains that can result is some cool looking domain names (e.g. sever.us)
• all the recent additions like .blog, .site, .name, etc

Still, I like the appeal of the original domains as they are all:

• cheap (usually around $10/year, while some “modern” domains go as high as $35/year)
• short (I prefer typing .net or .com compared to .engineer)
• widely known and recognized. I don’t know about you, but I’m still a bit surprised when I see sites using the newer “more exotic” domain names.

And of the originals, .net has the most appeal for me, at least when it comes to personal sites/blogs/etc.

Obviously, this wasn’t always the case - after all this site uses the domain batsov.com, and I own domains like metaredux.com and emacsredux.com. Let’s just say that back then I didn’t really think about the semantics of domain names that much. By the way, I do own batsov.net as well, and I actually use it for my personal email address.¹ I would have changed the domain for this site as well, if it was easier to setup redirects on GitHub Pages. Anyways, that’s not a big deal for me.

I guess the original domains have long lost their original semantics. I guess search engines tilted the scales in favor of .com (and .org to some extent). Still, there’s always some meaning behind a name and the best names tend to have a strong bond to that meaning. Naming is hard, but it’s also extremely rewarding once you get it right. I hope I’ve managed to spark your interest in .net and that over time you’ll grow to love and cherish it as I do. .net forever!

• Help wanted:
  • Looking for spacemacs power user for a 30m/1h lesson. (paid)
• Upcoming events:
  • M-x Research (contact them for password): TBA https://m-x-research.github.io/ Fri Nov 19 0700 Vancouver / 0900 Chicago / 1000 Toronto / 1500 GMT / 1600 Berlin / 2030 Kolkata / 2300 Singapore
  • Emacs Berlin (virtual, in English) https://emacs-berlin.org/ Wed Nov 24 0930 Vancouver / 1130 Chicago / 1230 Toronto / 1730 GMT / 1830 Berlin / 2300 Kolkata – Thu Nov 25 0130 Singapore
• Emacs configuration:
  • Marcin Borkowski: y-or-n-p but with RET meaning yes
  • Philip K.: A somewhat brief update on setup.el
• Emacs Lisp:
  • Emacs Lisp book is finished (Reddit, HN)
• Appearance:
  • PSA: Emacs now distinguishes between "regular" and "medium" font weights
  • Christian Tietze: Use macOS System Selection Colors in LIN for Emacs Line-Selection UIs
  • Emacs Icon v2
  • SVG Hack for Emacs Display Engine
• Navigation:
  • yuri tricys: How to Find Just About Anything On Your Computer With Emacs Part 2
• Org Mode:
  • Eigenbahn: Custom Org-mode links abbrevs
  • Emacs TIL: Upload and insert hosted images into Org files
  • Jeremy Friesen: Creating a Documentation Dashboard and Emacs Function
  • org-roam-ui is now in MELPA! (Reddit)
  • Alvaro Ramirez: Plain Org has joined the chat (iOS) (Reddit)
  • [Appreciation] Org mode's new website
• Completion:
  • Protesilaos Stavrou: Emacs: mct is on GNU ELPA
• Coding:
  • Emacs IDE - How to Debug Your Code with dap-mode
  • PCB Design in GNU Emacs
  • Jeremy Friesen: Further Hacking on Emacs for Github Pull Requests
  • [WIP/RFC] Magit-like interface for Nix flake commands (Reddit)
• Web:
  • Using follow-mode and eww to make a multi-columned web browser (Reddit)
  • Lars Ingebrigtsen: Finally! Videos in eww
• Doom Emacs:
  • Emacs TIL: Setting up grammar check with Doom Emacs in Mac OS X (Reddit)
  • DoomConf November 2021 (Doom Emacs) (02:53:49)
• Community:
  • Weekly Tips, Tricks, &c. Thread
  • Lars Ingebrigtsen: 12x10%
  • Ask HN: Could VSCode be the new Emacs?
  • Talking about Emacs and Other Things (15:29)
  • System Crafters Live! - Editor Popularity: Does It Matter? (01:57:30)
  • Lex Fridman on Emacs (06:12)
• Other:
  • sndio.el - Emacs major mode for sndio(8) interaction
  • Jeremy Friesen: Send Anything in OS X to Emacs for Editing
  • editWithEmacs: Use emacs to edit any text field/text box in emacs (Reddit)
  • Will Schenk: Getting emacs working on OSX Monterey
• Emacs development:
  • Support abbreviating home directory of Tramp filenames
  • Expose xwidget navigation history to Lisp code
  • Move Info-goto-node-web to "G"
  • image-dired: Revamp slideshow functionality
  • Improve performance of 'file-name-case-insensitive-p' for Tramp files
  • Add a command to go the gnu.org version of the info page
  • xwidget: Add xwidget-webkit-buffer-name-format.
  • Support Tc terminfo flag for 24-bit color support in terminal
  • Options to automatically stop the Emacs server
  • Add `xwidget-webkit-load-html'
  • Add new function 'file-name-split'
  • Expand the etc/NEWS section about the `medium' font changes
  • Optionally use use xwidgets to display <video> elements in shr
  • xwidget.el: limit buffer-name flicker in mode-line
• New packages:
  • mct: Minibuffer and Completions in Tandem
  • dilbert: View Dilbert comics
  • eshell-info-banner: System information as your Eshell banner
  • evil-tree-edit: Evil structural editing for any language!
  • org-roam-timestamps: Keep track of modification times for org-roam
  • org-roam-ui: User Interface for Org-roam
  • tree-edit: A library for structural refactoring and editing
  • xwiki-mode: Major mode for xwiki-formatted text

Links from reddit.com/r/emacs, r/orgmode, r/spacemacs, r/planetemacs, Hacker News, planet.emacslife.com, YouTube, the Emacs NEWS file, Emacs Calendar and emacs-devel.

If you’re like me, you hate dealing with text outside of Emacs. Even those of us who spend as much time as we can inside Emacs have to interact with other applications. In my case, that’s mostly Safari. The problem with Safari is that its architecture doesn’t allow extensions that will call Emacs to edit text fields the way, say, Firefox does.

MacOS, of course, recognizes many of the Emacs keybindings but you can do much better. For many years, I’ve used the operating system’s ability to assign keys to editing functions to install a fairly comprehensive set of Emacs editing keybindings but while that helps with muscle memory, it’s not really like editing with Emacs. I’ve long wished for a way of popping into Emacs to edit the text fields from other apps.

Now, happily, my wish has been answered. Take a look at this video by dmgerman that demonstrates his Edit with emacs Everywhere package. It provides just what you’d want: if you’re in any text field in any Mac application, you can press a key sequence to put up an Emacs buffer in which you can edit the text in the field and then return the edited text to the calling app. The important thing here is that you’re not just using Emacs keybindings but using Emacs itself with all its power. Perfect!

The package depends on Hammerspoon to mediate with the OS. It’s easy to install and, of course, is more generally useful but even if it weren’t, giving us the ability to edit all text fields with Emacs is worth the price of admission.

You never get a second chance to make a first impression.

Your name is your brand. This may sound like a cliche, but it’s true. That’s why it’s a very good idea to make sure that when people search for you online the results they’ll see first are the results you want them to see - e.g. a nice personal site, a solid LinkedIn profile, some videos of you presenting at various conferences, etc.

I think everyone will agree that’s preferable to finding instead some goofy/embarrassing/sloppy content about you.¹ I guess all of us have some of it, and that’s okay, as long as it’s not dominating our online “brand”. Online anonymity is another option you can explore, but this will likely cost you all sorts of lost opportunities, so I wouldn’t recommend going in this direction. After all this effectively means that you don’t have an online “brand”.

You might be wondering where am I going with all of this. As usual - there’s a story behind the article. I recently Googled my name and I noticed that the first matches people get about me are:

• LinkedIn
• GitHub
• Twitter
• https://batsov.com
• Instagram
• Some talks on YouTube
• Patreon
• https://metaredux.com

Not too bad, given my 23 years of roaming the Internet, but still a bit disappointing, as I would have preferred for my personal sites to have ranked a bit higher.² At any rate - this search gave me a clear idea of what people come across when they look for “Bozhidar Batsov/bbatsov”, so now I know where should I focus my efforts if I want to build a strong personal brand. I search for myself every few months and I would recommend to everyone to do the same from time to time. Lately I’ve also been spending a lot time on updating and cleaning up (think) and Meta Redux, which made me ponder on the topic of personal brand even more.

So, how do you build a good online brand? In general it seems prudent to me that everyone should:

• have some (simple) personal site
• have a clean and up-to-date LinkedIn profile/public resume (especially if you’re looking for better gigs)

Why so? Well, this ensures you’re associated online with something other than your Facebook/Instagram accounts. Something you’ve crafted carefully and optimized for public consumption. You can obviously have a lot more online presence if you wish to - e.g. I like writing, so I have several blogs. If you don’t like writing there’s no need to force yourself to maintain a blog.

Here are a few guidelines for a good personal site:

• focus on the content, not the visuals³
• less (good) content is better than lots of (any) crappy content
• use a custom domain for your site, ideally something with your name in it (e.g. batsov.com or bbatsov.net in my case) - remember your name is your brand
• highlight there everything you think reflects the brand you’re aiming for (background, work, causes you’re passionate about, hobbies, life goals, etc)
• keep the site up-to-date - a broken or outdated site may reflect poorly on you

If you’re working in tech like me, and you’ve worked on some interesting OSS/hobby projects you might want to highlight those as well. If you’re working in another industry - I guess you know way better than me what to highlight.

All of these guidelines sound pretty basic, but it took me a few years to discover them organically myself. Much of my earlier articles here are so bad, that I’d happily delete them, but I keep them around to remind myself of the lessons I’ve learned and the experience I’ve gained. I don’t like LinkedIn much, so for many years my profile there was almost empty, but knowing that’s the first result many people get about me, I consider ignoring it a mistake. It’s not about getting more job offers, it’s about people finding something meaningful attached to my name.

When it comes to writing I strongly prefer to publish my articles on my own sites, instead of 3rd party services like Medium, dev.to, platforms that pay external authors for content and so on. Anything (meaningful) I wrote is a reflection of myself, so I’d rather it be closely associated with my name and my brand. That’s another argument in favor of picking domains with your name in it, instead of cool domains like ninjahacker.guru. Still, the content matters much more than the domain under which it’s published. There’s no substitute for good content.

That’s all I have for you today. A personal brand has many aspects, and the Internet is just one of them. There’s also the brand you have built in your community, on your job, etc. Those, however, are outside the scope of today’s short post on the subject. My thoughts were a bit messier than usual, but I hope I managed to get the message across. Now go create a great personal brand for yourselves!