Last week there were some quite interesting posts about windows management in Emacs — Emacs’ windows navigations and some Emacs zen (a review by Irreal), Emacs window management tweaking, for instance.

In this regard, I’ve decided to share my configuration for the issue.

For switching between windows in Emacs I use the ace-window package by Oleh Krehel aka abo-abo, a renowned author of such gems as Hydra, avy, Swiper, and others. Most of these packages have found their place in my .emacs.

My configuration is quite simple.

(use-package avy :ensure t)
(use-package ace-window :ensure t
  :after avy
)

(global-set-key [(f2)]  #'ace-window)

The main function, ace-window is meant to replace other-window by assigning each window a short, unique label. When there are only two windows present, other-window is called… If there are more, each window will have its first label character highlighted. Once a unique label is typed, ace-window will switch to that window.
…
By default, ace-window uses numbers for window labels so the window labeling is intuitively ordered.

I’ve bound ace-window to <F2>. Why <F2>? For ergonomic reasons. On most keyboards, the numeric keys (1-2-3-…) are located right under the <F2> key. It would be easy to press <F2> then, for example, 2 using the same finger.

The ace-window package has many other options; you can find more detailed information at the ace-window GitHub repository.

Happy emacsing!

— The Emacs Cat.

One of the strengths—or weaknesses, depending on your point of view—of Lisp is garbage collection. That means that memory no longer in use is automatically collected and made available to the system without depending on the programmer to release it the way we do in, say, C. Of course, that comes at a cost. Garbage collection can block other operations while it’s running. That’s especially true in the single threaded Emacs.

One often sees complaints about this in the various forums. There’s all sort of advice about what to do. Some say you should set the garbage collection threshold (the amount of collectible memory) high so that garbage collection isn’t triggered as often. Of course, that means that it takes longer to collect the unused memory.

Another suggestion is to set the threshold low so that unused memory can be collected quickly. That means, though, that garbage collection is run more often. Depending on your workflow, either—or possibly both—of these strategies may work well for you.

There’s a third, arguably better, strategy: only garbage collect when the system is idle. That’s facile advice, of course, because it begs the question of how you know when the system is idle. There’s a useful heuristic. If the system has been idle for x seconds it will probably continue being idle long enough for a garbage collection cycle. The question then boils down to the proper value for x.

Jack Jamison believes x should be small and uses 1.2 seconds in his implementation of this strategy. He says that he’s had excellent results with that value. The older GCMH system uses 15 seconds.

I’ve been using GCMH was several years and can’t remember having any garbage collection issues since I started. GCHH lets you configure the idle time but the 15 second setting has been working well for me so I’m not inclined to mess with it.

In any event, if your Emacs is experiencing garbage collection delays it’s worth trying this strategy. If you want a simple prepackaged solution, GCMH is for you. If you want to keep everything in your init.el and avoid external packages, take a look at Jamison’s post to get started.

Two Eamcs tweaks I forgot about (most of you will know these):

Use Consult’s recentf to see a list of files that were edited recently:

  (global-set-key (kbd "C-x C-r") 'consult-recent-file)

Consult’s org-agenda (jump to heading) is quicker than what I usually do, which is to list all ACTIVE keywords in emacs (this is how I list my projects), and then go down the tree to find the specific TODO header I want.

Since I often know what I’m looking for within active projects, I can use consult-org-agenda, which narrows headers dynamically as I search. Much faster and clutter-free:

  (global-set-key (kbd "C-c C-h") 'consult-org-agenda)

Back before I became an Emacser, a friend who was an Emacser said that I shouldn’t worry about the Emacs keybindings because I could configure them to be whatever I want. I remember thinking that that would be disaster. After all, what would I do if I were using Emacs on someone else’s computer or even setting up a new computer.

Now, of course, I have a very individualistic configuration that makes working on someone else’s computer uncomfortable. Uncomfortable but not impossible. That’s because although I have all sorts of specialized editing commands, I’ve left the “vanilla” editing commands—cursor movements, file visiting and saving, and other standard operations—alone. That means that if I use someone else’s Emacs I can edit successfully, if not optimally, as long as the guest Emacs also didn’t mess with the standard bindings.

That’s why I’m not entirely sympathetic to The MKat’s post on how to unset default key bindings. She’s got a lot of great advice on how to delete keybindings and I agree that it’s useful information to have. My objection is to the notion that you should delete bindings that you don’t like.

Just yesterday, I discussed how modern keyboards aren’t optmal for Emacs so it’s natural to want to fix that somehow. Yesterday’s post suggests some ways of doing that but none of them involve changing default keybindings.

Sure, some folks have special needs that make one binding or another difficult but in general, I think it’s a bad idea to be messing with them. Of course, this is Emacs and everyone can adjust it to their liking. I’m not arguing with that. I’m only saying that if you stay with the defaults it will be easier for you to use an alien Emacs.

Over at the Emacs subreddit, surveypoodle asks a perennial question: what are the best keyboards for Emacs? He points out that Emacs pinky seems to have appeared rather late in the editor’s history and speculates that that’s because the keyboards originally used with Emacs were better suited for it than modern keyboards that make many of the bindings awkward. He’s asking what modern keyboards are best for dealing with RSI.

If you’re interested in an answer to the question, see the comments to surveypoodle’s post. There are all sorts of suggestions. Reading through them, I realized that I didn’t care.

I used to yearn for a reincarnation of the Space Cadet keyboard—okay, I still have some vestigial urges—but I realized that these days I do virtually all my work on my laptop. I’m guessing the same is true many of us. Regardless, the use of a laptop pretty much makes the choice of a keyboard for you. Sure, you can use a third party keyboard but unless you’re always working at (the same) desk it’s just too much trouble. As I’ve said before, I do a lot of my work on the couch so an external keyboard isn’t a practical choice for me.

What to do? As much as it has become a cliche, Emacs pinky—or more generally Emacs induced RSI—is a real thing.The best solution I’ve found is some simple keyboard modifications. I’m using a MacBook Pro so keyboard firmware modifications aren’t an option. What I can do, though, is arrange for the modifier keys I use the most to be easy to reach. Two of those, Ctrl and Hyper are, configurable from within Emacs or macOS. The Meta key is bound to Alt by default so there’s nothing to do there. What all this means is that binding Ctrl to caps lock and Hyper to ⌘ Right Cmd, I can use my thumbs for Meta and Hyper and that Ctrl is an easy reach for my pinky.

I know that a lot of you are doing the same or similar things. If you’ve got a better solution, leave a comment.

If you’re an Emacs user (which I know you are), especially one who lives in dired-mode, you’re probably familiar with the quick power of isearch for finding files or directories. But if you’re like me, you might have noticed a tiny speed bump in the workflow: after finding a file or directory with isearch, you would typically have to hit <enter> to exit the search, and then <enter> again to open the entry. That’s two steps for something that feels like it should be one and this has been a very minor annoyance for me for a very long time now.

I had a little time to shave some more yak hair, so lets try and address this!

The solution I came up with was to add a bit of advice to isearch-exit, so now, when you’re in dired-mode and you use isearch to locate a file or directory, pressing <enter> will both exit the search and immediately open the file or directory, no need for a second confirmation.

Here’s the magic!

(defadvice isearch-exit (after dired-enter-directory-or-file activate)
  "In dired mode, enter directory or open file after isearch."
  (when (eq major-mode 'dired-mode)
    (let ((file (dired-get-file-for-visit)))
      (when file
        (dired-find-file)))))

The only thing I am a little worried about are the side effects, but I guess we shall see…

And another thing, now my dired navigation is one step smoother; how much time generally is it going to save me? Was it worth the effort?.

Let’s say, conservatively, that I have pressed that extra Enter 100 times each day. Each press takes, say, 150 ms, accounting for human reaction times, even though it isn’t really a reaction, more of a muscle memory response.

Let’s do the calculations! I have no idea why I’m doing this, but maybe I can validate the amount of time I spent on this for future time-saving gains. Maybe it will make me feel better about the countless hours of yak shaving I have done over many years (with Emacs, of course, although I do have a yak in the garden shed that really needs some attention!)

So, the savings are as follows:

• Day: 15 seconds
• Week: 105 seconds
• Month: 7 minutes
• Year: 1 hour 24 minutes

Well, the yearly total is probably about the amount of time I actually took to implement this, so that means in a year I will be making productivity gains! Sweeeeeeet!

The doric-themes is my new in-development package for Emacs. It is a set of themes that conform with a minimalist aesthetic: they use few colours and appear monochromatic in many contexts. Below are the screen shots.

In terms of my overall theme work for Emacs, the doric-themes are the most minimalist, ef-themes the most maximalist, and the modus-themes remain what I consider the best “default theme” style. All of them are designed to be highly legible.

I plan to add doric-themes to GNU ELPA within the next days. For the time being, they are only available from source code: https://github.com/protesilaos/doric-themes.

Finally, the backronym for “Doric” is “Doric Only Really Intensifies Conservatively”.

Enjoy your new theme!

Samples

doric-light

doric-marble

doric-earth

doric-wind

doric-dark

doric-obsidian

doric-fire

doric-water

• Upcoming events (iCal file, Org):
  • Emacs.si (in person): Emacs.si meetup #5 2025 (v #živo) https://dogodki.kompot.si/events/5302f53d-05cd-437b-b885-80f07d307f31 Tue May 13 1900 CET
  • OrgMeetup (virtual) https://orgmode.org/worg/orgmeetup.html Wed May 14 0900 America/Vancouver - 1100 America/Chicago - 1200 America/Toronto - 1600 Etc/GMT - 1800 Europe/Berlin - 2130 Asia/Kolkata – Thu May 15 0000 Asia/Singapore
  • M-x Research: TBA https://m-x-research.github.io/ Wed May 21 0800 America/Vancouver - 1000 America/Chicago - 1100 America/Toronto - 1500 Etc/GMT - 1700 Europe/Berlin - 2030 Asia/Kolkata - 2300 Asia/Singapore
  • Emacs APAC: Emacs APAC meetup (virtual) https://emacs-apac.gitlab.io/announcements/ Sat May 24 0130 America/Vancouver - 0330 America/Chicago - 0430 America/Toronto - 0830 Etc/GMT - 1030 Europe/Berlin - 1400 Asia/Kolkata - 1630 Asia/Singapore
• Upcoming events:
  • Emacs APAC: Announcing Emacs Asia-Pacific (APAC) virtual meetup, Saturday, May 24, 2025
• Emacs configuration:
  • A few tweaks to Emacs (without elisp) to make it nicer (03:45)
  • Hiding Buffers in Emacs (Reddit)
  • Opening the Emacs Initialization File, or First Impressions Matter (Reddit, Irreal)
  • New Emacs Distribution: Nox Emacs
  • James Dyer: Discovering Treasures in Emacs-solo
  • dotfiles/.spacemacs at main · basteez/dotfiles (@basteez.bsky.social)
  • jjba23/sss: Supreme Sexp System - SSS 2.3.15 (@sss_project@mastodon.social)
  • minimal-emacs.d - init.el and early-init.el with Better Emacs Defaults and Faster Startup (Release: 1.2.1) (Reddit)
• Emacs Lisp:
  • Enhancing Git Diff for Emacs Lisp: Better Git Diff of Elisp function or macro definitions (Reddit, Irreal)
• Appearance:
  • Colourless themes for Emacs
• Navigation:
  • Hoagie's corner of the internet - Emacs: toggle narrowing (Reddit, Irreal)
  • TIL sr-speedbar for navigation (@lhp@mastodon.social)
  • TAONAW - Emacs and Org Mode: Emacs' windows navigations and some Emacs zen (Irreal)
    • TAONAW - Emacs and Org Mode: window management, terminology
• TRAMP:
  • Tip: TRAMP supports Gnome online accounts, so you can use it for Nextcloud files
• Org Mode:
  • My Exobrain - This is how I'm keeping my Org-mode files organized (Reddit, @jworthe@fosstodon.org)
  • Consistent Technical Documents Using Emacs and Org Mode Applying Literate Programming to Technical Writing
  • Jack Baty: Set point at first heading when opening Org mode file
  • Org-mode: Select a heading for link with completion, but use ID property for link heading text as default description · GitHub
  • (release) org-include-inline
  • catsup: pomodoro timers, Org (@caranmegil@mastodon.social)
  • On Orgmode and Obsidian: PTPL 151 · Why the Openest of Open Formats Isn’t the One for Me - Ellane W
  • @noctuaminervae is the new Worg maintainer (@bzg@floss.social)
  • Org Mode requests: [FR] Adding custom indices for Texinfo export (and maybe unaffiliated dual-value keywords?)
  • Org Mode requests: [FR] Accept nil outline path for file+olp+datetree org-capture-templates target
• Completion:
  • Tim Heaney: Magic completions in rust-analyzer
• Coding:
  • Tip: jq-interactive lets you run and edit dynamic searches across the current json buffer (@choffee@mastodon.me.uk)
  • Improving Frappe Developer Experience in Emacs | Ruthra Kumar (33:46)
  • A New Way to Edit Jupyter Python Notebooks in Emacs (Reddit)
  • Marcin Borkowski: Coloring Git output in Magit
  • Introducing nix-flakes.el: A Simple Emacs Package for Managing Nix Packages
• Shells:
  • Shell Scripts in Emacs: The Cyber Ghost’s Shortcut to Flow – Tom's IT Cafe (@TomsITCafe@mastodon.social)
  • Tip: sh-execute-region
• Doom Emacs:
  • IT'S ALIVE !! Doom Emacs On Windows (23:12)
• Fun:
  • dynasty-reader.el: Read MANGA comics in Emacs
• AI:
  • Control Emacs with Model Context Protocol (MCP) (04:05, (Reddit)
• Community:
  • Fortnightly Tips, Tricks, and Questions — 2025-05-06 / week 18
  • Emacs Elements channel is back!
• Other:
  • emacs — Matt Gemmell (@mattgemmell@mastodon.scott)
  • Jeremy Friesen: Migrating to Linux: Getting Emacs Installed (@takeonrules@dice.camp)
  • orgrr update: orgrr-super-compile-sequence (@laotang@mastodon.social)
  • The Emacs widget toolkit | Aleksandr Petrosyan (HN)
  • BSAG » All the editors (@bsag@social.lol)
  • Progress on Emacs Lisp interpreter in Scheme
• Emacs development:
  • emacs-devel:
    • Re: Failure building Emacs master on MSYS2 [MSYS2 PKG]​ - x86_64-pc-cygwin seems to be the future
    • Third-Party url.el replacement or wrapper packages
    • Re: Failure building Emacs master on MSYS2 [MSYS2 PKG]​ - msys supposed to be used only to build tools required to build packages using Autoconf
  • Fall back `eww-switch-to-buffer' to `eww'
  • New vc-async-checkin user option
  • Recenter for the calendar (bug#78205)
  • Derived types (i.e. 'cl-deftype') can now be used as method specializers
  • lisp/register.el (register-read-with-preview-traditional): Use PRED
  • ; * etc/NEWS: Add 'comment-setup-function'.
• New packages:
  • bookmarks-menu: Add a Bookmarks menu to the menu bar (MELPA)
  • cuckoo-search: Content-based search and saved-searches for Elfeed (MELPA)
  • jsonp: Resolve JSON pointers in ELisp objects (MELPA)
  • tomlparse: A straight-foward tree sitter based parser for toml data (MELPA)

Links from reddit.com/r/emacs, r/orgmode, r/spacemacs, r/planetemacs, Mastodon #emacs, Bluesky #emacs, Hacker News, lobste.rs, programming.dev, lemmy.world, lemmy.ml, planet.emacslife.com, YouTube, the Emacs NEWS file, Emacs Calendar, and emacs-devel. Thanks to Andrés Ramírez for emacs-devel links. Do you have an Emacs-related link or announcement? Please e-mail me at sacha@sachachua.com. Thank you!

You can e-mail me at sacha@sachachua.com.

Courtesy of JTR from The Art Of Not Asking Why, here’s a handy tip for dealing with window placement when bringing up a Dired buffer. There are two problems.

The first doesn’t really concern window placement. Most often JTR wants to bring up a Dired buffer for whatever directory he’s already in. The easy way to do that is to use dired-jump (bound to Ctrl+x Ctrl+j) to open a buffer in the same directory as the current file.

The problem with that is that it opens the Dired buffer in the current window. JTR doesn’t want that. He wants to open Dired in some other window so that he can see his current file and the Dired buffer. The answer to that is simple: just ask Emacs to open Dired in another window. There’s a general protocol for doing that. Simply use Ctrl+x 4 Ctrl+J to call Dired. That will open Dired in the same directory as the current file but in another window.

The Ctrl+x 4 … works for a lot of commands. I use it to open files or buffers in another window several times a day. I used to consider it an esoteric maneuver but now I use it all the time. You can also open your windows in another frame by using 5 instead of 4.

The 4/5 protocol doesn’t work for all commands but it does for a lot of them. It’s a real time saver that I use repeatedly. It’s well worth internalizing.

This month’s Emacs Asia-Pacific (APAC) virtual meetup is scheduled for Saturday, May 24, 2025 with BigBlueButton and #emacs on Libera Chat IRC. The timing will be 1400 to 1500 IST.

The meetup might get extended by 30 minutes if there is any talk, this page will be updated accordingly.

If you would like to give a demo or talk (maximum 20 minutes) on GNU Emacs or any variant, please contact bhavin192 on Libera Chat with your talk details:

Charles Choi makes an astute observation about the Emacs initialization file from the point of view of the new user: there’s no obvious way of loading it or even knowing that it exists. The problem is especially acute on the Mac where the File → Open menu uses the Mac file loading routines that don’t show dot files. Not very helpful even if you know the name of the file.

Choi is surprised that this far on the problem hasn’t been fixed. It’s hard to argue. On the other hand, I don’t remember having this problem. I have no memory at all of how I overcame it but I and thousands of others have. That doesn’t mean that the problem isn’t real, though.

Choi offers a solution. It’s a simple function that loads the init file even if it hasn’t been created yet. His idea is that the function would be builtin and automatically available to the new user.

Of course, the problem is how does the new user discover this function, or for that matter, what to do with the init file once it’s loaded. It seems to me that at the very least there needs to be some instructions on the startup screen—you know, that screen we all turn off as soon as we learn how. That would help but it’s probably not enough.

What’s really needed is a new-user file that explains how to get started. It could be linked from the startup screen. It wouldn’t need to be long or complicated; just enough to bootstrap the new users and point them to the tutorial.

One thing for sure: Choi is right. It’s really harder than it should be for a new user to learn enough to get up to speed with Emacs.

As I was looking more into widows management in Emacs, particularly viewing System Crafters' video about the topic which I mentioned in my previous post, I learned a couple of things (or maybe re-learned? I probably used to know about them at some point in the past).

One of my issues with windows in Emacs right now is that whenever I open Dired, it takes over my current window. I often just want to view my files in the directory my current buffer is in.

The answer is simple: instead of opening Dired (C-x d), just “jump” into Dired in another window, which is dired-jump-other-window or C-x 4 C-j. This improves my workflows twice: first, I usually want to open Dired in the directory the buffer I’m working in is, and second, I want it in another window. With this command, I don’t need to specify the directory; it just takes me where I want¹.

Also, as I was writing this post, I realized another problem with Emacs windows placement was actually my problem all along (user error dance, anyone?): C-x b is bound to consult-buffer-other-window on my system, which does what it says, opening the buffer I want in the other window. I thought this was the command to open a buffer, forgetting that there’s such a thing as opening a buffer in the other window. Using the logic I just learned, it would probably make more sense to bind consult-buffer-other-window to C-x 4 b (for me, it runs the default Emacs switch-to-buffer-other-window, which I don’t use²) and then consult-buffer (which is not bound to anything for me) to be C-x b. This will disrupt my muscle memory for a while, but eventually it will lead to a better workflow.

Another nice thing I didn’t know and learned from watching this video is that I can scroll up and down in the other window while still keeping the focus on the current buffer with M-pgup and M-pgdn. This is nice if I want to read help documentation while working on something, reading definitions with Emacs' built-in dictionary, or maybe using Occur or something similar, where just reading for reference is enough.

Then we have a built-in way to move between windows that I was looking for a while: windmove. Turns out it’s been there since Emacs 21, which means that for me, it was there all this time, and I didn’t know about it. Windmove lets you switch between windows using the shift and arrow keys by default, so that S-up would move you one window up, while S-down will move you down. You need to enable it and then enable its default keybindings, or assign it alternative keybindings.

Looking at these key-bindings, I can see why it’s turned off by default. Shift plus an arrow key is used extensively in org-mode, for example, so you can’t use these keys. Using something else, say, C+M+left or C+M+right, is not good either because on Linux, this will “swish” your workplaces (“spaces” in macOS), while the meta key plus an arrow is also taken by something else in Emacs… you get the idea, finding the keys to use is getting a bit problematic. You need to figure out what you can give up, or find a creative shortcut that works for you specifically. However, this seems too useful to pass up, so I think I’m going to dedicate keys to it very soon.

The video also goes over windmove’s sibling, windmove-swap-states-[direction], which switches the windows in the direction you tell it. So if I am working on this post in a window that is above a list of links I’m using as reference in the window below in another buffer, I can use windmove-swap-states-down to switch. Now I will be working in the lower window, and the list of links will be in the window above. This is good if I want my list of files in Dired to the window to the right, but dired-jump-other-window opened it in the window below, for example. Nice, it saves a few C-x 0 and C-x 1 maneuvers.

Then there are the external packages, of course. ace window is probably the most popular one, and this video provides a brief demonstration of it. The idea is that it numbers the windows for you on the screen, and then you select a number to jump to a window. Another package I learned about is winum, which is built on top of this idea, but it displays the window number in the minibuffer of each window all the time, and then it’s a matter of C-x # to jump to that window. It integrates into Emacs better in my opinion, and if you use many windows, it probably makes sense. I usually have no more than four windows open at once, so using the built-in windmove is probably better.

Alright, I’m off to rebind some keys and do some tweaking! Then we will see how much I need to mess with Emacs’s built-in logic for windows placement. It might just make a little more sense now.

Footnotes

¹: it’s building on dired-jump (C-x C-j), which opens dired in the directory the buffer I’m in. So, if I’m working on bills.org, which is under ~/Documents/personal/, dired-jump will open dired inside ~/Documents/personal/. The problem for me is that it will take over my current buffer (where I have bills.org open), which I don’t want; this is where dired-jump-other-window comes in: it will open Dired in a separate window.

²: this Emacs keys and windows management rabbit hole makes me re-appriciate Emacs’s default key binding. They’re there for a reason. They might not make sense at start… or maybe for several years, depending on how often and how much you use Emacs and what for, but now I see how C-x 4 is an entire family of key combinations tied to “other window” functions and then other key bindings start to make sense. For some of you veteran Emacs users, this might be obvious, but for me, that’s a slap on the forehead with a “Ohhh! So this is why this keybinding is like this!”

Raw link: https://www.youtube.com/watch?v=0N7vshEYOok

On Sunday, the 11th of May 2025, at 14:00 o’clock of time zone Europe/Athens, I will do a live stream where I will answer every question posted in the chat. The idea is to cover any of the topics I already write/talk about on my website, including Emacs, my recently published “Emacs Lisp Elements” free book, libre software, politics, philosophy, and everyday affairs.

I will answer every question from top to bottom to the best of my abilities and will not give any of those formulaic non-answers. No tricks; no gimmicks!

The plan is to do a minimum of two hours, but may extend it for at least one or two more hours depending on the participation in the chat.

The event will be recorded: no worries if you cannot make it live.

Talk to all of you soon!

In working on the on-boarding for Scrim, I’ve recently had to consider the scenario of setting up a fresh install of GNU Emacs on macOS (as of this writing v30.1). A number of things struck me, particularly on the user experience (or lack thereof) for new users of Emacs, nearly all of whom will be unfamiliar to Emacs commands and keybindings.

1. There is no dedicated command to load the Emacs initialization file (in this case ~/.emacs, which has yet to be created).
2. Using the menu bar (File › Open File…) will open a macOS File Browser dialog window, but does not show hidden files (like .emacs) by default.
3. The customize-variable command only works on variables that have been loaded.

On point 1, it’s striking to me that this hasn’t been done already like… decades ago. New users won’t know a priori what the Emacs initialization file is (sidestepping the inside baseball of .emacs vs init.el) much less that such a file is not immediately created at the first launch of Emacs but the ~/.emacs.d/ directory is.

Further exacerbating this is point 2, where the menu bar action File › Open File… will open a native macOS file dialog instead of running find-file. However this dialog is not configured to show hidden files. When the dialog is raised, the user can use the macOS key-binding Command + Shift + . to show hidden files, but this is hardly a discoverable feature.

On point 3, while I’ve long been an advocate for using customize-variable, it fails for variables that are not autoloaded (in this case server-use-tcp). A partial work-around is to run the command describe-variable which should implicitly load the package containing a non-autoloaded variable in order to describe it (although I would not be surprised if there are cases where you really have to load the package via require). Once the variable is described, a link is provided to customize it. Arguably, such details should never be surfaced to a new user.

Going back the lack of a dedicated command to load the Emacs initialization file, here’s some Elisp that implements it. Note that the variable user-init-file is already set to ~/.emacs for a fresh install.

1
2
3
4

(defun find-user-init-file ()
  "Edit `user-init-file'."
  (interactive)
  (find-file user-init-file))

For most experienced Emacs users, this command has little value but it's not meant for them. It's meant for new users and should be built-in. First impressions matter!

Over at the Emacs subreddit, sebhoagie has a short post that some of you may find useful. Sebhoagie really likes narrowing and uses it all the time. Sometimes, though, the narrowed code refers to code outside the narrowed region and he occasionally wants to reference it and then return to the narrowed region.

That’s not a big problem of course. Just widen, search for the referenced code, highlight the original narrowed code, and renarrow. Of course there’s a bit of friction and if you need to do it often it can become a burden.

Sebhoagie has a writeup that explains his solution. The TL;DR is that he wrote a function that narrows to a region but when you widen, it remembers the narrowed region. If you narrow again (using his function) it will renarrow to the previous region and forget the saved region parameters. If you think it through, that does exactly what you want. When you’re finished with the narrowed region you simply widen in the normal way (with widen) and everything is reset.

My solution is to use Artur Malabarba’s narrow-or-widen-dwim that almost always does exactly what I want. Take a look at Malabarba’s post to see how it works. If you’re not using it, you’re definitely working too hard. Still, you may find sebhoagie’s useful. If you have a similar need, his code is a nice companion to Malabarba’s.

Narrowing really can be a superpower as sebhoagie says and it’s worthwhile making its use as easy as possible.

I’ve been using Mastodon as my only social media for a while now. I started on mastodon.social, but moved over to Fosstodon after a while, desiring a slightly smaller, more focused instance. That was fine for a while; the local timeline was actually useful and I found some people to follow from there.

Over time though, I found myself not caring so much about the local timeline and I’d occasionally see some complaints about the fosstodon moderation policies. I didn’t love that, but setting up my own Mastodon server seemed like a huge pain - demanding minimum system resources, lots of care & feeding.

Things reached a head recently though, over some more extreme issues with Fosstodon’s moderators and some people I follow had stated they would be defederating from Fosstodon immanently. Trying to find a new server that wasn’t itself going to have moderation problems sounded tiring and I don’t exactly have a lot of free time right now, but I did remember hearing more recently about GoToSocial as a Mastodon-compatible Fediverse server that was much lighter to run. I took a quick look at the setup instructions, decided that it seemed like less work than finding a “good” Mastodon server, so I spun my own instance up!

I was really impressed with how easy it was – I don’t much care for Go as a programming language, but static binaries do make installation really straight-forward – just untar, set up some config files, and I was off! I also appreciated how the installation instructions weren’t just “use Docker”; I much prefer running things without containers.

I made my own theme as well to match my blog, which was also quite straight-forward – just make a CSS file and scp it up to the appropriate directory.

I’m very happy with my new home on the Fediverse now! I also updated my “socials” footer here to have a more general “fediverse” logo instead of the Mastodon-specific one, since I’m no longer riding the elephant. It feels satisfying in this age of the internet consolidating into like four websites run by billionaires to have one’s own little corner of the internet, as cozy and kind of weird as you like it.

While exploring Emacs-solo, I was struck by how closely its philosophy aligned with my own Emacs-DIYer project. The parallels were sometimes uncanny, for example, we had independently chosen identical keybindings like “M-s g” for grep functionality. I had been also considering “M-s f” for my find variant and was looking for a home for recentf, potentially at “M-g r”. There were also some ideas around using other finding tools such as ripgrep and fd as a callout to some external tools and there were many other similarities.

I was particularly intrigued to see newsticker included, as I had recently adopted it as an elfeed replacement. The ace-window alternative implementation also closely mirrored my own single-defun approach.

So, with my first pass through, I have picked out the following goodies to be purloined and incorporated into Emacs-DIYer

• dired icon replacements
• Git gutter status overlay
• Hide completion buffer when icomplete in buffer
• ollama alternative directly from ansi-term

Firstly, the dired icon replacement provides visual clarity without requiring the all-the-icons packages. While perhaps not essential, it gives me a comfy feel and I think these icons significantly improve the Emacs experience, particularly for frequent dired users like myself.

I pretty much just copied the entire emacs-solo-dired-icons section but stripped out the use-package as I’m trying to keep Emacs-DIYer compatible with older versions of Emacs. This worked straight out the box (like all the other integrations) and I just needed to make sure I have the requisite font collection installed.

The git status indicator in the dired gutter was a welcome addition I hadn’t previously implemented or even considered. It provides immediate visual feedback that feels natural and intuitive, especially coming from a background of extensive version control experience.

Having used subversion for over 20 years (before transitioning to TortoiseSVN and then magit and vc), I was already accustomed to status characters like “M” indicating modified files and other single key status key definitions seem consistent to my previous experience, and isn’t it great to see them visible in dired!

In summary, this integration complements my existing modeline status indicator, along with vc and gives me both file-specific and directory-level version control visibility, noice!

I had been working on replacing corfu/company with in-buffer completion, but hadn’t solved how to hide the completion buffer when using icomplete. My settings already closely matched those in Emacs-solo, but the critical missing piece was this elegant advice:

(if icomplete-in-buffer
    (advice-add 'completion-at-point
                :after #'minibuffer-hide-completions))

Now it feels much cleaner and I might start using it rather than corfu from now on.

The final act of pilfering is to incorporate a simple ollama integration.

Before creating my Ollama Buddy package, I had explored integrating ollama through a shell and I had also come to the conclusion that using ansi-term was really the only quick solution, but I just couldn’t figure out the implementation details. However, the experience ultimately led me to take an alternative approach, writing a small implementation to interface with ollama from an Emacs buffer, which eventually gave rise to Ollama Buddy.

The Emacs-solo ansi-term solution feels surprisingly well-integrated once you become comfortable switching between line and character modes. I’ve now incorporated this as an alternative to my API-based implementation, providing two no-dependency options for local LLM access!

I plan to further explore Emacs-solo, particularly for additional vc enhancements. This first pass has already yielded valuable improvements to Emacs-DIYer, and this has been a valuable exercise to learn from another project with such similar design principles.

I recently discovered Org mode’s speed keys option and it’s pretty great. One caveat with speed keys is that they only work if the point is at the very beginning of a heading. To help with this, I (with Claude’s help) created a small lisp function and hook to move the insertion point to the beginning of the first heading whenever I open an Org mode file. I’m recording it here in case it’s useful to anyone else.

(defun my/org-goto-first-heading ()
  "Move point to the beginning of the first heading in an org file."
  (when (eq major-mode 'org-mode)
    (goto-char (point-min))
    (if (re-search-forward "^\\*+ " nil t)
        (goto-char (match-beginning 0)))))

(add-hook 'org-mode-hook 'my/org-goto-first-heading)

I had to disable the saveplace package but I don’t mind. This is better, since I don’t often want to return to where I was last editing a document.

I wouldn’t be shocked to learn that there’s a simpler way to do this, but this works for now.

With my Migrating to Linux: On Guiding Principles and Keyboard Bindings complete, I moved on to getting tool of my computering: Emacs.

I think my Emacs 📖 configuration requires at least version 29.1; however I’m uncertain. The package manager had Emacs 27 available, so I opted to build from source.

I could either download a released version’s source code or clone the repository. I chose the clone route; as this would be useful as upgrades come out.

Preliminaries:

sudo apt update && sudo apt install git --assume-yes

With git installed I need a copy of the Emacs repository, and should build from a stable ref; as of <2025-04-23 Wed> that is emacs-30.1. (Sidenote: I had a copy of the Emacs git repository on another machine. So I used the sneaker net (e.g. a thumbdrive) to copy that over to the Linux 📖 machine and then run git pull so I could get up to date source code.)

I used Installing Emacs 29.1 from source on Debian 12 · GitHub as my framing.

First, building the dependencies:

sudo apt build-dep emacs
sudo apt install libtree-sitter-dev libgcc-12-dev libgccjit-12-dev

Then making a home for my new install:

mkdir -p ~/.local/emacs

In my source directory for Emacs (e.g., ~/git/emacs/), I ran the following:

./configure \
--prefix="$HOME/.local/emacs/" \
--without-compress-install \
--with-native-compilation=aot \
--with-x \
--with-x-toolkit=lucid \
--with-gif \
--with-png \
--with-jpeg \
--with-tiff \
--with-imagemagick \
--with-mailutils \
--with-tree-sitter \
CC=gcc-12

It took a few tries, which is why I have the CC=gcc-12 declaration as well as instructions for installing libgcc-12-dev and libgccjit-12-dev.

Now came time to spin up the fans. I ran make -j 16; where 16 is the number of cores on my machine. And finally make install.

Along the way, I realized that there were terminal commands that I was missing. But I could hobble along.

Up until I had Emacs built, I was using nano to write my notes. It is quite serviceable.

Note, I could have installed Emacs 30.1 via the Pop Shop, however I chose to build from source.

Toggling Gnome Settings

There are a few settings that I have found useful to toggle:

• Trackpad and Night Light
• Light/Dark Theme
• Radios

Trackpad and Night Light

With my new laptop and how I hold my hands, I’ve noticed that sometimes I activate my trackpad. Which is annoying, especially when I’m in a “writing mindset.”

I don’t like the bright blues of a normal screen. Instead I prefer to use a display setting that softens the colors. In Macintosh Operating System (MacOS 📖) this is “Night Shift.”

I choose a much warmer color, knowing that reds are softer on the retina. (Sidenote: My mom has a retinal disease and her research and recommendations from experts leads her to incorporate more red filters in her day to day.)

Both of these settings are similar in how they are toggled. So I wrote some Emacs Commands for Setting Toggling.

Emacs Commands for Setting Toggling

With the toggles identified, I set about writing the functions and macros to help with future needs.

To create my Trackpad toggling command I call my jf/linux:gsettings-toggler Emacs macro. Below is the code:

(jf/linux:gsettings-toggler "Trackpad"
  :property "org.gnome.desktop.peripherals.touchpad send-events"
  :match "'enabled'"
  :on_match "disabled"
  :on_miss "enabled")

The first parameter is the named concept (e.g., “Trackpad”). The :property is the gsettings key that I’m looking to change (e.g. “org.gnome.desktop.peripherals.touchpad send-events”). The :match value is what I check as the property’s current state. When the current value is a match, I set the property to the :on_match value.

And below is how I generate my Night Light toggling command:

(jf/linux:gsettings-toggler "Night Light"
    :property "org.gnome.settings-daemon.plugins.color night-light-enabled"
    :match "true"
    :on_match "false"
    :on_miss "true")

As of <2025-05-03 Sat> the generating macro is as follows:

(cl-defmacro jf/linux:gsettings-toggler (name &key property match on_match on_miss)
    "Toggle the NAME setting via the PROPERTY.

When the PROPERTY is a MATCH set the property to ON_MATCH; otherwise set
it to the ON_MISS value."
    (let ((docstring
            (concat "Toggle " name " for Gnome desktop."))
           (func-name
             (intern (concat "jf/linux:toggle-" name))))
      `(defun ,func-name ()
         ,docstring
         (interactive)
         (let ((value
                 (if (string= ,match
                       (s-trim
                         (shell-command-to-string
                           (concat "gsettings get " ,property))))
                   ,on_match ,on_miss)))
           (shell-command
             (concat "gsettings set " ,property " " value))
           (message "%s: %s" ,name value)))))

Light/Dark Theme

Related but different from the Night Light concept is the Light and Dark theming. In Emacs I had a script to toggle the theme of both the OS and Emacs (e.g. my jf/dark function). I wanted something similar in Linux .

Yet, as I explored the changes, I realized that there would be a divergence in implementation based on MacOS or Linux .

Toggling the light and dark theme is a bit different; as this requires coordination. My jf/color-scheme-system-toggle command handles both the MacOS and my Linux install.

(defun jf/color-scheme-system-toggle ()
    "Toggle system-wide Dark or Light setting."
    (interactive)
    (pcase system-type
      ('darwin
        (progn
          (shell-command
            (concat "osascript -e 'tell application \"System Events\" "
              "to tell appearance preferences "
              "to set dark mode to not dark mode'"))
          (jf/color-scheme-set-for-emacs)))
      (_
        (let ((lightp
                (eq :dark (jf/current-color-scheme-gnome))))
          (dolist (fn jf/color-scheme-system-toggle-functions)
            (funcall fn lightp))))))

The Linux toggling portion determines if the scheme is :dark, and uses that boolean value to pass to each of the toggling functions.

My jf/color-scheme-system-toggle-functions variable (which I realized is misnamed) defines a list of functions that I’ll call, passing true when I want to set them to the “light” theme. Below is that variable’s definition:

(defvar jf/color-scheme-system-toggle-functions
    '(jf/color-scheme:gnome-color-scheme
       jf/color-scheme:gnome-gtk-theme
       jf/color-scheme:copyq-theme
       jf/color-scheme:emacs-theme)
    "A list of arity one functions that set component schemes based on the
input parameter.

When the parameter is non-nil, favor the dark option.  Otherwise favor
the light option.")

The four functions that toggle my system scheme are similar but just different enough:

• jf/color-scheme:gnome-color-scheme
• jf/color-scheme:gnome-gtk-theme
• jf/color-scheme:copyq-theme
• jf/color-scheme:emacs-theme

Below is the definition of those four functions:

(defun jf/color-scheme:gnome-color-scheme (lightp)
  "Set the gnome color scheme based on LIGHTP (e.g. light/dark)."
  (shell-command
   (format
    "gsettings set org.gnome.desktop.interface color-scheme prefer-%s"
    (if lightp "light" "dark"))))

(defun  jf/color-scheme:gnome-gtk-theme (lightp)
  "Set the gnome gtk theme based on LIGHTP (e.g. light/dark)."
  (let ((theme
         (if lightp "Adwaita" "Adwaita-dark")))
    (shell-command
     (format
      "gsettings set org.gnome.desktop.interface gtk-theme %s"
      theme))))

(defun jf/color-scheme:copyq-theme (lightp)
  "Set the copyq theme based on LIGHTP (e.g. light/dark)."
  (shell-command
   (format
    "copyq loadTheme %s/solarized-%s.ini"
    (s-trim
     (shell-command-to-string "copyq info themes"))
    (if lightp "light" "dark"))))

(defun jf/color-scheme:emacs-theme (lightp)
  "Set the emacs theme based on LIGHTP (e.g. light/dark)."
  (ef-themes-select
   (plist-get jf/themes-plist
              (if lightp :light :dark))))

An astute reader might notice some duplication of my jf/color-scheme:gnome-color-scheme and jf/color-scheme:gnome-gtk-theme and the toggling macro. There’s a potential refactoring there, but I’m going to leave it on the idea shelf.

Radios

By default, I like to keep my Bluetooth off. I wanted a way to turn this off and on via Emacs . And also turn off and on my WiFi.

Below are my functions to go radio silent and start broadcasting:

(defun jf/linux:radio-silence ()
    "Soft block laptop radios (e.g. bluetooth and wlan).

Related to `jf/linux:radio-broadcast'."
    (interactive)
    (shell-command "rfkill block all"))

  (defun jf/linux:radio-broadcast (&optional all identifiers)
    "Soft unblock laptop radios (e.g. bluetooth and wlan)

When ALL is non-nil unblock all radios.  Other unblock only the wlan.

Related to `jf/linux:radio-silence'."
    (interactive "P")
    (let ((identifiers
            (mapconcat
              (lambda (el) el)
              (or identifiers '("wlan"))
              " ")))
      (shell-command
        (concat "rfkill unblock "
          (if all "all" identifiers)))))

I don’t have a physical switch, so I settle for the soft programmatic block.

Grabbing Links

Part of my writing workflow is grabbing links from my browser (and RSS 📖 feed). On MacOS I use GitHub - xuchunyang/grab-mac-link.el: Grab link from Mac Apps and insert it into Emacs. And I explored GitHub - xuchunyang/grab-x-link: Grab links from some X11 apps and insert into Emacs.

However, that wasn’t quite enough. So I wrote up some changes for my own needs; namely to address having multiple applications based on Firefox. Along the way I learned about xdotool and comm.

Conclusion

With Emacs installed, I could really set about my documentation process. My next article in this series will be about other applications I use: Virtual Private Networks (VPNs 📖) , browsers, terminal, and connecting to Github.

James Cherti has a quick tip on configuring Git to provide more meaningful diffs for Elisp files. The problem, he says, is that by default Git diffs simply provide a line-by-line difference with no added context such as what functions are involved. It turns out that it’s pretty easy to provide that context.

The process is pretty simple. First you have to provide a regular expression that recognizes the various def constructs such as defun and defmacro. Then you tell Git to associate that regex with Elisp files. After doing that, you get a bit more context in your Git diffs.

Take a look at Cherti’s post for the details. It’s a small thing but easy to do and it may make your change analysis a bit easier.

By default, the git diff algorithm compares changes in Elisp files line by line without understanding the structural semantics of Emacs Lisp files. This means that when modifications are made within functions, the diff output does not convey how those changes relate to higher-level code constructs such as functions or macros.

As a result, reviewers are presented with fragmented and often verbose diffs where the context of a change, such as which function it belongs to, is not always readily apparent. This lack of structural awareness can make it difficult to assess the purpose and impact of changes efficiently.

Git can be configured to recognize function or macro definitions explicitly, ensuring that diffs are presented at the function or macro level rather than as arbitrary line changes. Here are the steps:

Step 1 – The Git configuration for Emacs Lisp diffs

Add the following elisp Git driver to your ~/.gitconfig file:

[diff "elisp"]
xfuncname = ^\\([^[:space:]]*def[^[:space:]]+[[:space:]]+([^()[:space:]]+)

The regular expression above matches lines that begin with typical Emacs Lisp definition forms, such as defun, defmacro, and other def* constructs. It detects the symbol being defined, allowing Git to handle changes at the function or definition level intelligently. This configuration can also be found in the autogen.sh file, which is part of the Emacs source code.

Step 2 – Associating the Git Diff Driver with *.el files

Once the custom diff driver is defined, it needs to be associated with Elisp files. This is accomplished by adding the following line to the ~/.gitattributes file:

*.el diff=elisp

With this setup, Git will apply the elisp diff driver to all files with the .el extension, using the custom pattern to identify function boundaries.

Conclusion

This configuration generates diffs that focus on changes within the scope of individual function and macro definitions, rather than arbitrary lines. As a result, reviews of Emacs Lisp code become more precise and contextually relevant. Reviewers can easily identify which functions were modified, without being distracted by unrelated or excessive diffs.

Related links

• The configuration in this article is part of the author’s ~/.gitconfig file is available in the jc-dotfiles repository.
• Enhancing Git configuration ~/.gitconfig for performance, efficiency, data integrity, and workflow automation
• git-diff documentation

• Help wanted:
  • Emacspeak: update to support TCL 9?
• Upcoming events (iCal file, Org):
  • Emacs Paris: S: Emacs workshop in Paris (online) https://emacs-doctor.com/ Tue May 6 0830 America/Vancouver - 1030 America/Chicago - 1130 America/Toronto - 1530 Etc/GMT - 1730 Europe/Berlin - 2100 Asia/Kolkata - 2330 Asia/Singapore
  • EmacsATX: Emacs Social https://www.meetup.com/emacsatx/events/306966612/ Wed May 7 1600 America/Vancouver - 1800 America/Chicago - 1900 America/Toronto - 2300 Etc/GMT – Thu May 8 0100 Europe/Berlin - 0430 Asia/Kolkata - 0700 Asia/Singapore
  • Atelier Emacs Montpellier (in person) https://lebib.org/date/atelier-emacs Fri May 9 1800 Europe/Paris
  • EmacsSF (in person): coffee.el in SF https://www.meetup.com/emacs-sf/events/307404994/ Sat May 10 1100 America/Los_Angeles
  • Emacs.si (in person): Emacs.si meetup #5 2025 (v #~ivo) https://dogodki.kompot.si/events/5302f53d-05cd-437b-b885-80f07d307f31 Tue May 13 1900 CET
  • OrgMeetup (virtual) https://orgmode.org/worg/orgmeetup.html Wed May 14 0900 America/Vancouver - 1100 America/Chicago - 1200 America/Toronto - 1600 Etc/GMT - 1800 Europe/Berlin - 2130 Asia/Kolkata – Thu May 15 0000 Asia/Singapore
• Emacs configuration:
  • Add missing prefix-key descriptions to Which-key
  • Christian Tietze: My Current Compilation Window Display Settings in Emacs via display-buffer-alist
  • TAONAW - Emacs and Org Mode: Emacs window management tweaking
  • My first Elisp code: a package for per-project commands (Reddit)
• Emacs Lisp:
  • Emacs Buffer Local Functions (01:54) - fset-local
  • el-pa parallel multithreading on multicore, Emacs-to-Emacs TCP solution for Elisp (Reddit)
  • Emacs Package Development: The Emacs Reader (II: Making Overlays Centered and Zoomable) - 5/4/2025, 5:34:51 PM - Dyne.org TV
  • Ep651 emacs lisp coding, text processing (57:21)
• Appearance:
  • Emacs zoom!
  • Emacs Themes Gallery for your Daily Procrastination Needs
  • Protesilaos Stavrou: Emacs: ef-themes version 1.10.0
  • Creamy Emacs (@mms@mastodon.bsd.cafe)
• Navigation:
  • Automatically Create Parent Directories on Visiting a New File in Emacs - Iqbal Ansari
• Dired:
  • Rahul Juliato: Improving Dired in Emacs Solo: Git Status and File Icons (Reddit)
• Writing:
  • 1000 words: Warn if you use any word that is not in one of the 1000 or 2000 words in Brown corpus; helps with writing prose in simple English
• Org Mode:
  • Org Mode requests: [FR] file+olp+datetree accepting function to select target file
  • Org Mode requests: [FR] Accept nil outline path for file+olp+datetree org-capture-templates target
  • TIL: using C-c C-x C-d in #emacs #orgmode shows the clock in column view
  • Import, export, and integration:
    • Tip for using ox-clip to copy formatted text in Org Mode
    • federicotdn/verb: HTTP client for Emacs (lobste.rs)
    • Generate Beamer Slides From Org Mode
    • TAONAW - Emacs and Org Mode: org-mode, dired, and journelly
    • kanban.el 0.2.5: special handling for links within the file: do not add the file as prefix (@ArneBab@rollenspiel.social)
    • Charles Choi: Announcing Scrim - An Org Protocol Proxy for Emacs on macOS (Reddit, Irreal)
  • Org development:
    • Merge branch 'km/from-emacs-master'
    • Backport commit 702cb123f from Emacs
    • ox-html: Always wrap exported src block with <code> tag
• Coding:
  • How do you run common development tasks (tests, checks, migrations, environment…)? - includes snippet for use with .dir-locals.el
  • Meta Redux: CIDER 1.18 ("Athens")
  • devcontainer.el - Adding support for Visual Studio Code-compatible devcontainers (https://containers.dev/) to Emacs (Reddit)
  • Marcin Borkowski: Improving my Emacs-Jira integration
• Web:
  • emacs-websearch: duckduckgo is now supported (Reddit, Irreal)
• Mail, news, and chat:
  • twtxt.el 1.0: stable and final version
• Doom Emacs:
  • Slackware-15.0: Doom Emacs Install (v02) (22:19)
• AI:
  • Augmentation / Replacement | olano.dev
  • Emacs in the Golden Age of LLMs
  • Peter Povinec: Towards Auto-Generated ERT Unit Tests
  • James Dyer: Ollama-Buddy 0.9.38: Unload Models, Hide AI Reasoning, and Clearly View Modified Parameters on each request
• Community:
  • Are there any non-programmers who use Emacs? (Irreal)
  • Detecting Emacs Package Synergy - Crafter Hours (02:20:58)
• Other:
  • 25 Useful Tips for Emacs (for beginners and advanced users) (@revrari@mastodon.social)
  • oantolin/scimago: Download Scimago data, look it up in Emacs with completion (@oantolin@mathstodon.xyz)
  • View Disk Partition in Emacs (Reddit)
  • Intstalling Emacs with systemd-sysext - Alex Carney (@alcarney@mastodon.social)
  • Tanimoto, Steven L. Challenges for Livecoding via Acoustic Pianos Proceedings 2017, (ICLC 2017, Morelia, Mexico.) (@frescosecco@mastodon.social)
• Emacs development:
  • emacs-devel:
    • Re: master 6b11687555c: New user option native-comp-async-on-battery-pow
    • Re: Enabling native-comp when frequently rebuilding master on a laptop - issues with recompiling
  • Add line-column tracking for tree-sitter
  • New user option native-comp-async-on-battery-power
  • New this-command buffer display action alist entry
  • Allow selecting what to copy when installing a local package
  • Fix custom type of 'flymake-show-diagnostics-at-end-of-line'
  • New log-edit-maybe-show-diff option for log-edit-hook
• New packages:
  • gptel-magit: Generate commit messages for magit using gptel (MELPA)
  • jupyter-ascending: Edit Jupyter Notebooks in plain text (MELPA)
  • weather-scout: Display weather forecast from MET Norway (MELPA)

Links from reddit.com/r/emacs, r/orgmode, r/spacemacs, r/planetemacs, Mastodon #emacs, Bluesky #emacs, Hacker News, lobste.rs, programming.dev, lemmy.world, lemmy.ml, planet.emacslife.com, YouTube, the Emacs NEWS file, Emacs Calendar, and emacs-devel. Thanks to Andrés Ramírez for emacs-devel links. Do you have an Emacs-related link or announcement? Please e-mail me at sacha@sachachua.com. Thank you!

You can e-mail me at sacha@sachachua.com.

MarchZealousideal543 over at the Emacs subreddit asks a familiar question: Is it really feasible or even possible for a non-programmer to use Emacs productively? I know I write about this a lot but I find the subject fascinating. MarchZealousideal543 got steered onto Emacs by asking some AI for suggestions and apparently Emacs was the overwhelming recommendation.

There’s nothing very interesting about such questions, of course; the interest is in the comments. There’s the usual ankle biting and nonsense but a lot of the comments are excellent and tell stories of how people from all walks of life—even someone in construction—use Emacs to run their lives, careers, or businesses.

The one thing that many of them say, though, is that you should expect to spend a few weeks getting up to speed with Emacs. Those of us who have been using Emacs for decades and still consider ourselves barely up to speed can only smile. Nevertheless, they all say that the startup time is worth it and that you will soon become proficient.

The other story that came up more than once was how the secretaries at the MIT were introduced to Emacs and given a small write up on how to configure it. Because they didn’t realize they were programming, they soon were soon automating their workflows.

If, like me, you like reading about non-technical people using Emacs, take a look at this reddit post.

Windows in Emacs probably come to you as second nature now, as it does to me, but imagine how it looks to people from the outside for a minute:

Look at the diagram on the screen. Read the explanation. Look at the “huh?” expression of David of System Crafters (awesome channel for Emacs learning by the way)… Need I say more? 😂

I love Emacs, don’t get me wrong, but when it comes to managing its windows…

If you’re one of those brave folks who doesn’t mind browsing the Web from within Emacs, I just came across a package that may interest you. It’s emacs-websearch a small utility that lets you specify a term, search for it on the web, choose one of the results, and open that page in your Emacs.

That may sound a little complicated but take a look at the animated GIF at the link. It seems like a pretty nice workflow. Right now, it supports Duck Duck Go and Google but looking at the code, it would be easy to add your favorite. You can choose between using the xwidget toolkit and eaf-open-browser to display the Web page.

This is one of those small packages that mainly scratches the author’s itch but can still be useful to the rest of us. Take a look and see if it might work for you.

For the longest time, I had my compilation buffers split to the right in a rather large window.

Until I started programming in Emacs.

Previously, I looked at LaTeX build outputs, or the static site generator’s progress. That was it. Lots of logged text, so I wanted the space.

But compiling C++ or Swift code compulsively, as I do, this got on my nerves really quick. So here’s a more normal configuration, showing compilation-mode buffers in a 25% bottom split “side window” (essentially a sidebar, but anywhere).

(defun ct/display-buffer-compilation-mode-p (buffer-name action)
  "Determine whether BUFFER-NAME is a compilation buffer."
  (with-current-buffer buffer-name
    (or
     (eq 'compilation-mode (buffer-local-value 'major-mode (current-buffer)))
     (string-match (rx "*[Cc]ompilation*")
                   buffer-name))))

(add-to-list 'display-buffer-alist
             '(ct/display-buffer-compilation-mode-p
               (display-buffer-at-bottom 
                display-buffer-in-side-window)
               (window-height . 0.25)
               (side . bottom)
               (slot . -6)))

I’m not matching for (derived-mode-p 'compilation-mode) because that also catches rg.el and ag.el buffers. (I used to auto-hide compilation buffers and got terribly confused and annoyed that my search results wouldn’t show anymore.)

I still make Emacs Lisp compile warning windows not show at all, via https://protesilaos.com/codelog/2024-11-28-basic-emacs-configuration/:

 (add-to-list 'display-buffer-alist
             '("\\`\\*\\(Warnings\\|Compile-Log\\)\\*\\'"
               (display-buffer-no-window)
               (allow-no-window . t)))

Ah, and as of today, I’ve tagged all my posts including display-buffer-alist because I’ll definitely tweak these again and again.

Hire me for freelance macOS/iOS work and consulting.

Buy my apps.

Receive new posts via email.

I didn’t sleep well last night (it was too hot and humid for what I’m used to), so as a way to quiet my brain down, I turned to Emacs tweaking as always. This time, something that’s been driving me nuts for a while: Emacs' way of managing windows.

By default, Emacs' usage of windows doesn’t make sense to me. New windows open in seemingly random places, and modes that are supposed to help with the current buffer (like help for example) start out of focus, meaning you have to switch to them (C-x b) to scroll and read. When using several windows, this mess can quickly get out of hand.

To organize Emacs windows the way I want them to, I need to play around with display-buffer-alist. By default, its value is nil— meaning Emacs does what it does by default.

Micky has a good article explaining how Emacs prioritizes its windows by default and how display-buffer-alist works, while Port has a helpful visual tutorial with examples.

I like how Prot explains that an alist is a “list of lists,” so what we’re working with here is giving Emacs lists as guides as to how to display its windows. The way it works for each list is basically:

1. Define what is the “trigger” for a rule
2. Define what guides or functions to follow for that trigger
3. Define additional parameters (additional “tweaks”)

Here’s what I have so far:

    (setq display-buffer-alist
          '(
            ;; trigger: when the major mode is dired-mode:
            ((derived-mode . dired-mode)
            ;; guides: show me the above (dired) in a side window:
            (display-buffer-in-side-window)
            ;; paramaters: what side? right. How wide? .80:
            (side . right)
            (window-width . 80)
          ))
    )

This works, but it has a couple of functional problems.

1. In general, I prefer Dired to open to the right. I want to open another Dired window. In that case, I want it to open under the existing dired window. I usually open two Dired windows when I work with dwim for file functions, like renaming/moving files from one place to another. I doubt I’ll need to open three dired windows, but if I do, the idea should be the same: keep opening more Dired windows under the existing Dired windows.

2. The width is fixed, and I find .80 to be OK, but sometimes, this is too much, especially when the overall Emacs window (the frame) is already small. If I call Dired, I want Emacs to increase the size of the entire frame if it’s under a certain size.

3. I want to make sure Dired doesn’t delete or occupy other existing Dired windows, since that defeats the purpose of working with dwim. Each Dired window should have its own window, as I stated above: the first to the right, and the rest under the existing ones.

I’ve already been watching videos and reading for an hour and a half, and I’m getting sleepy again, so I think I’ll attempt to fill my sleep bank some more.