I was reading the Wikipedia page for Emacs and found this statement:

>As of 2025, GNU Emacs has had 1,608 individual committers throughout its history.

This made me curious about how first-time contributors to Emacs are distributed over time. I took a local checkout of the Emacs mirror repository and scanned the commit history. For each commit, I recorded the Git author name and email, treated the pair (author_name, author_email) as an identity, and then kept only the first commit where each identity appears. Finally, I plotted the cumulative number of distinct authors over time. I used Git's .mailmap normalization (git log --use-mailmap) to map known name/email variants to the same person when the repository provides such mappings.

This is just a quick/fun experiment, not a rigorous study. There are obvious caveats. The most obvious ones are possible duplicated identities not covered by .mailmap.

Still, the cumulative plot surprised me. It seems to show two very different slopes, with a clear change around 2010: before then, relatively few new author identities appear per year; after then, the number rises much faster.

What is good news for me: Emacs did not decline in popularity. It can still attract new contributors, presumably younger fellow Emacs enthusiasts.

Does anyone know what explains the change around 2010? Was it related to migration away from older version-control workflows, when migrating from CVS to Bazaar and then Git, or simply to a change in how patches were attributed to their original authors?

I have been experimenting with an extension of agent-shell that directly renders equations as SVGs in the chat.

• SVGs render with perfect resolution; no pixelated effect.
• Equation size is matched to the font size.
• When changing font size, all equations rescale correctly.
• You don't need to give any particular instructions to your agent; just tell it not to render inline equations as markdown inline code because there is no unambiguous way to know whether it is an equation to be rendered or just real code.
• When you switch theme or foreground/background colors, the SVGs will switch automatically.
• And it is fast.

I am just amazed by Emacs, how incredible and powerful it is, allowing crazy customization of packages.

And big shout out to agent-shell... it is the best it is one of the best integration of agents in Emacs.

Side note: You can also run Claude CLI directly in ghostel.el inside Emacs. Ghostel is so good and fast that the UX feels just as smooth as running Claude CLI inside your favorite terminal app instead of Emacs. But the Claude CLI harness can't render equations -- which is what patching agent-shell makes possible.

I am so excited to see how Emacs can empower coding harnesses. It makes the experience inside Emacs better than what shipped from the factory. Crazy.

PS: For those interested: I also prepared a little video (no audio; just about 1 minute presentation)

https://www.youtube.com/watch?v=wGM3xH06Wso

showing how fast equations are rendered when produced by the agent. It also shows in the end that I can change the font size and all equations rescale correctly.

P.S.: People pointed out there is also gptel and probably a few other Emacs harnesses for code agents that are also very good. I have tested only very few so far. So, in fairness, I cannot say whether agent-shell is the best integration of coding agents for Emacs as I originally wrote; it is certainly an excellent one.

I would like to share with you a lightweight package, straight-overview, that gives you a compact overview of which packages are outdated. The screenshot speaks better than any word for what you get.

The package is directly inspired by dired (e.g., it defines its own faces, which inherit from dired faces; so you don't necessarily have to customize its faces twice if you already did it for dired with your theme).

It uses a read-only, table representation. You can sort packages by the number of days of how far behind the last commit your installed package is.

Motivation

I don't feel comfortable with straight-pull-all command, which essentially installs into your config the latest version of all packages, without you being able to first take a look at what is going to be installed.

Moreover, I like to update packages bit by bit, to avoid the all-at-once update effect and having to chase bugs without understanding what package caused them. It is rare, but some packages can break things, and if you update too many packages at once it makes debugging the problem more difficult and you may get more than one unpleasant surprise.

Credits

I discussed the idea in the latest Fortnightly Tips, Tricks, and Questions. I need to thank two redditors, u/djr7c4 and u/BBSnek, who gave me the right ideas, like using straight-fetch-all and how to organize the table of the overview (the idea is directly copied from subtree-package).

Niceties

If you press c you get the list of commits you are lagging behind. If you have magit installed (most of you probably do), it relies on magit to show that list as a magit-log buffer, so each commit is actionable and you can profit from magit's commit-viewing (e.g. magit-show-commit) right there. Without magit, it falls back to a plain git log listing.

Interaction / Bindings

I directly copy from the README.md page how you interact with it.

Key	Action
m	mark package at point for update
u	unmark
U	unmark all
M	mark all outdated packages
x	pull marked packages (and rebuild, if enabled)
P	pin the package at point at its current commit (hold)
F	free (unpin) the package at point
R	restore the package at point to its pinned commit (no-op if unpinned)
c	show changelog (HEAD..upstream) for package at point — a magit-log buffer when Magit is available (each commit actionable), else a plain git log listing
o / RET	open the package's repo in a browser
a	toggle outdated-only / show all packages
g	re-scan from local refs (no fetch)
G	straight-fetch-all, then re-scan

Configuration

All settings are explained in the README customization section.

I just want to point out that by default, straight-overview-fetch-on-open is set to nil, meaning that the package does not automatically fetch the new commit infos when it opens. This is how I like it because fetching takes a few seconds and I like it to manually trigger it by pressing G when I believe I need to refetch.

Little gotcha for the non-git-specialists: when the package calls straight-fetch-all (which is provided by straight itself), this command is very different from straight-pull-all. The fetch operation retrieves updates from a remote repository without changing your local files; instead, the pull operation fetches updates and merges them into your current branch. So, fetching is perfectly safe and will never break your Emacs config by fetching some "wrong" package update. The whole point of this package is indeed to avoid automatically pulling all packages without getting an overview.

I have been using LaunchBar (https://obdev.at/products/launchbar/index.html) for more than 10 years to call recent files on my Mac. It is a mighty launch app. It is often underrated, and it is not as hyped as other launcher apps, but it is a true workhorse.

I regularly use LaunchBar to switch from other apps to Emacs or to open any random files on my Mac in Emacs (press Apple+G when LaunchBar is activated, and it will bring the selected file to LaunchBar, and then you can send it to Emacs).

Since months ago I moved to fully using Emacs as my go-to editor, I decided to write a little LaunchBar Action to open Emacs' recent files based on recentf:

https://github.com/alberti42/List-Emacs-Recentf-From-LaunchBar

The LaunchBar action to open recentf files is a total no-brainer. Any of you can create a similar function with essentially a single Claude prompt; so the value is not much in the code but in sharing the idea to use LaunchBar to list and open Emacs' recent files. Of course, feel free to directly download the action from my repo and run it if you don't want to recreate it by yourself.

If you like LaunchBar, I also wrote over the years a bunch of other LaunchBar Actions to list the recent files of several other apps like Mathematica, MATLAB, Photoshop, Illustrator, Acrobat, Word, PowerPoint, etc. Check this page, https://alberti42.github.io/, if you are interested.

PS: I have no affiliation or shared interest with LaunchBar. I have just been a normal user of the app for many years.