The people who live in a Golden Age usually go around complaining how yellow everything looks.
– Randall Jarell
Yesterday I wrote that I think Emacs is currently experiencing its (second) Golden Age.1 Today I’ll expand on this and I’ll offer my perspective on the reasons and factors that lead to it.
Yesterday someone mentioned on X the following:
I think @emacs was kind of revived thanks to VSCode (LSP) and Atom (tree-sitter).
While having access to shared editor infrastructure definitely helps, I think that’s only a tiny part of the reasons for Emacs’s “resurgence” in recent years. I believe that numerous factors played a part in this and I’ll try to list the ones I consider the most important. I’ll list those in no particular order in the sections that follow.
The creation of GitHub in 2008 was a revolution for OSS developers around the world. It was a massive step forward from the days of SourceForge and EmacsWiki, and a ton of Emacs projects were born on it.
I rarely contributed to OSS projects before the birth of GitHub, but drastically changed afterwards. GitHub was a big part of my OSS work and all of my projects are still hosted there. Its scale and reach allowed projects to connect with numerous potential contributors. Many of the most impactful Emacs packages in recent history were born and popularized on GitHub.2
I think it a bit ironic that a proprietary platform did so much for FOSS community, but I don’t think anyone can argue with the results. I won’t dwell much on this section, as I doubt that anything I can say about GitHub will be news to anyone.
Around the same time (in 2007) Clojure was created. The language generated a ton of interest in excitement in the programming community when it was released and this translated into increased interest in Emacs. Why so?
Well, Emacs was the first editor to provide some decent support for Clojure programming - clojure-mode
(a slightly modified version of lisp-mode
)
and a Clojure adapter for SLIME (swank-clojure
). CIDER (the successor of SLIME + swank-clojure
) is still one of the most popular and
most powerful Clojure programming environments today.
I’ve noticed that many of the active contributors to the Emacs community were connected to Clojure in some way. Here are a few examples:
technomancy
), a prolific Emacs hacker. He had also made one of the most famous “intro to Emacs” back in the day - Meet Emacs.dash.el
, multiple-cursors.el
and many others)I’m reasonably sure that Clojure played a major role in the success of Emacs in recent years by attracting both new users and new contributors to the project.
There’s more to the story, though. Clojure also had some impact on the core Emacs APIs, as macros like if-let
and thread-first
and libraries like dash.el
and seq.el
were influenced by it.
Sadly many Emacs packages were a total mess a few years ago. Many maintainers would never cut releases and users were just expected to use the latest version of the code.
This made the concept of a package repository that’s distributing only “tagged” releases problematic. Not to mention that package.el
was very new and wasn’t popular enough
to encourage people to change their ways. Do you remember that many Emacs packages weren’t using VCS and were distributed only on EmacsWiki? Fun times!
MELPA was a true revolution was it was released - a repo that was building snapshot release packages from a ton of sources (GitHub, person code repos, EmacsWiki). It was trivial to add a package there and it was a “one and done” thing (unlike its predecessor Marmalade, when you had to upload each new release manually). You’d just submit a package recipe and MELPA will rebuild your package when needed.
Today MELPA hosts a whopping 6000 (!!!) Emacs packages and its’ a true pillar of our community. For context - the official GNU ELPA and NonGNU ELPA repos are home to about 650 packages. I don’t know about you, but I’ve discovered a lot of cool packages while browsing MELPA and I can’t imagine the Emacs community without it.
Without going into much details:
What would you add to this list?
Spacemacs showcased the full potential of Emacs to a lot of people and managed to convert many Vim users to Emacs. That’s no small feat!
It wasn’t the first Emacs distro by any means, but it was the most ambitious one at the time for sure. Its decision to leverage heavily evil-mode
and to target
Vim users turned out to be a great choice!3
Emacs “Distributions” (a.k.a. “starter kits”) in general were quite important to bridge the gap between the spartan default Emacs experience and what users of the other editors would often expect. Today we have many of them, but I still believe that Spacemacs had the biggest impact on the community overall.
Emacs was getting a lot of criticism for lacking some of the advanced code analysis and refactoring capabilities of “modern” editors and IDEs. Its adoption of the industry standards LSP (Language Server Protocol) and TreeSitter changes this and makes sure Emacs developers don’t have to invest time solving problems that are already solved elsewhere. I’m guessing that in the long run this will allow the Emacs maintainers to focus more on the features that make Emacs unique and that’s a great thing in my book.
The complete transition to LSP and TreeSitter won’t happen overnight and we’ll need years to finish it. Still, the progress to date is nothing short of amazing. Exciting times ahead!
Richard Stallman stepped down as the head maintainer of Emacs in 2008, and was succeeded by a string of more progressive Emacs maintainers. I think that Stefan Monnier, John Wiegly and Eli Zaretskii have helped create an environment that’s collaborative and welcoming to contributions.
Here we can highlight a few major milestones:
package.el
as the standard package manager (bundled with Emacs 24 in 2012)Probably there are other extremely important achievements resulting from the actions of the head maintainers that I’ve forgotten about. Feel free to mention those in the comments.
You can never be wrong by being yourself.
While the editors of the day (e.g. VS Code) get the job done they aren’t necessary a great fit for everyone. There will always be those of us who are looking for something different for whatever reasons.
Given how similar most editors are today, those who are not happy with the status quo don’t really have that many options. If you want an editor that’s different from the mainstream and has a strong community - it’s essentially a choice between Emacs and Vim.
And if you want to build an editor that’s uniquely tailored to your preferences in every conceivable way - it’s probably Emacs.
Success occurs when opportunity meets preparation.
– Zig Ziglar
As you can see - that was quite the journey, that spans over 15 years. If I had pick one year that was the most important for what followed next it would probably be 2008:
What a year!
So there you have it - my take on the factors and the events that lead to Emacs’s second Golden Age. Is there anything you’d disagree with? Is there anything important that you think I’ve missed? Please, let me know in the comments!
You’re here because you know something. What you know you can’t explain, but you feel it. You’ve felt it your entire life, that there’s something wrong with the world. You don’t know what it is, but it’s there, like a splinter in your mind, driving you mad. It is this feeling that has brought you to me.
– Morpheus (“The Matrix”)
So, why should you try Emacs in 2024?
You’re now ready to begin your life-long journey to Emacs mastery. Meta-x forever! In parentheses we trust!
See https://batsov.com/articles/2024/02/26/emacs-dead-and-loving-it/ ↩
I can only guess what the impact to Emacs would be if it’s main development happened on a similar platform. ↩
Vim users should also check out Doom Emacs. ↩
What is dead cannot die.
– A Song of Ice and Fire (a.k.a. Game of Thrones)
Emacs was originally created in 1976. I was born in 1984. I’ve been using Emacs as my primary editor since 2005. Back then GNU Emacs was still reeling from the schism with XEmacs1 and a lot of people felt that the project might be near the end of its long and storied history. I recall the Emacs development wasn’t moving particularly fast at the time, modern text editors and IDEs (e.g. TextMate and Eclipse) were on the rise, and there were quite a few articles proclaiming the death of Emacs. Yet Emacs is still here 19 years later and some of the editors and IDEs that were popular in 2005 are not. This year Emacs will turn 48 years, which is an amazing achievement for any piece of software!
Last week another Reddit thread on Emacs’s death created some ripples in the Emacs community. I didn’t even read it, because it’s always more or less the same:
Highly subjective personal preferences aside, people often conflate how popular something is with how good or lively it actually is. If you look at the market share of Emacs, things definitely don’t look great:2
On the other hand, both the upstream Emacs development and the ecosystem of third-party packages feel to me more active than ever. At a time when some people are ready to write off Emacs as dead yet again, I’d be more inclined to pronounce a “Golden Age of Emacs”.3
Why so you might ask. Here are a couple of reasons that immediately come to mind:
seq.el
, map.el
, subr-x.el
, project.el
, xref.el
, etc)vim
)pgtk
). This means that Emacs 29 works natively on Wayland (and Windows 11 + WSL by association).Much of this happened in the last 5 years, which is pretty amazing for a dying editors that has been rendered irrelevant but its vastly superior competitors.
It amuses me how many people keep chasing after shiny and new things, even if they don’t really need them. Emacs has covered all of my use-cases for so long that I don’t even bother to upgrade to the new releases right way. I’m writing this article in Emacs 28, as I didn’t really have much of an incentive to upgrade to Emacs 29, despite it packing a lot of improvements. Even if Emacs didn’t add any few features for the next decade I’d be a pretty happy camper.4 Perhaps that’s a reflection of my appreciation for minimalism, perhaps I’ve grown wiser with age, but I’m no longer equating “progress” with “more”.
I’ve written at length about the merits of Emacs in the past, so I’m not going to repeat myself here. I’ll just remind you about the old saying “Don’t judge a book by its cover”. Or by it’s popularity or marketing campaigns for that matter. Essence is what matters, not superficial appearances.
Whatever doesn’t kill you simply makes you stranger.
– The Joker (The Dark Knight)
Emacs is certainly a very strange editor by modern standards. I’m guessing that’s the main reason why so many people quickly dismiss it. But its remarkable resilience is an indication that it’s probably made of stronger stuff than most editors. If you want to invest into a tool that has stood the test of time and will probably continue to be useful 50 years down the road - your options besides Emacs are quite limited…
It’s true that Emacs was at one point one of the two most popular text editors in the world, but those days are long gone and there’s little point in dwelling on them. Still, today it probably has a lot more users in absolute terms than in the 80s and early 90s. World domination is not a big priority for Emacs, but it may still be in the cards, given the average lifespan of many of its competitors.
Emacs is no more dead than usual and it likes it that way. M-x forever!
See https://survey.stackoverflow.co/2023/#section-most-popular-technologies-integrated-development-environment ↩
And I’m not the only one who thinks this way. ↩
I also need some time to catch up with everything new from the past few years. Emacs is so dead that its users can’t catch up with all the progress it makes from the grave! ↩
drop
, drop_while
, take
and
take_while
in the List module.1 What’s weird is that the similar
Seq module features all those functions
since OCaml 4.14.
Fortunately, that’s finally changing! While perusing the OCaml
changelog a few days ago, I
noticed a reference to a recently merged pull
request that adds the missing List
functions. It’s interesting that this PR is a follow-up to another PR that was a
bit more ambitious and was created way back in Oct
2020. Oh, well - better late than
never, right?
As you can imagine there’s nothing fancy about the implementation of the new functions:
let take n l =
let[@tail_mod_cons] rec aux n l =
match n, l with
| 0, _ | _, [] -> []
| n, x::l -> x::aux (n - 1) l
in
if n < 0 then invalid_arg "List.take";
aux n l
let drop n l =
let rec aux i = function
| _x::l when i < n -> aux (i + 1) l
| rest -> rest
in
if n < 0 then invalid_arg "List.drop";
aux 0 l
let take_while p l =
let[@tail_mod_cons] rec aux = function
| x::l when p x -> x::aux l
| _rest -> []
in
aux l
let rec drop_while p = function
| x::l when p x -> drop_while p l
| rest -> rest
Pretty standard recursive implementations. If you’re not familiar with
@tail_mod_cons
- it’s basically tail-call optimization for ::
(a.k.a. cons
)
in the final position of a recursive function.2
It seems the new List
functions will be shipped with OCaml 5.3. OCaml 5.2 is
not out at the time I’m writing this, but I’m guessing the PR missed the merge
window for 5.2. In the mean time - we can continue to rely on the excellent
Containers
library
for that functionality.
That’s all I have for you today. Keep hacking!
I believe it was Haskell that populirized them. ↩
See https://v2.ocaml.org/manual/tail_mod_cons.html for more details. ↩
Why are those developments notable? AsciiDoc started life in 2002 as AsciiDoc.py, but after the original project stagnated, the Ruby implementation AsciiDoctor became the most popular processor and eventually it kind of became the AsciiDoc standard.2 For many years in my mind AsciiDoc and AsciiDoctor were essentially the same thing. Still, AsciiDoctor was never “The Standard”, at least not officially. As noted in the specification proposal:
The specification for the AsciiDoc language will include an open source specification document, which defines required and optional API definitions, semantic behaviors, data formats, and protocols, as well as an open source Technology Compatibility Kit (TCK) that developers can use to develop and test compatible implementations. (Those of you who know Dan and I from before Asciidoctor know that an open source TCK is a hard requirement for us). A compatible implementation, as defined by the EFSP, must fully implement all non-optional elements of a specification version, must fulfill all the requirements of the corresponding TCK, and must not alter the specified API.
For users and developers alike, the AsciiDoc specification will mean a clear, working definition of what AsciiDoc is and how it should be interpreted. Developers will be able to build implementations, tools, and services around AsciiDoc without risk of diluting its meaning or splintering it. In turn, users will have more options, greater document portability, and the assurance that compatible implementations and tools will handle their AsciiDoc documents according to a versioned specification.
That’s pretty important, and it’s something that Markdown has not achieved yet. The lack of a common Markdown language standard has resulted in the creation of many slightly incompatible implementations (e.g. GitHub-flavoured Markdown) and some semi-successful standardization efforts like CommonMark.
You can find the AsciiDoc language specification here. One interesting thing that I noticed is that final spec will remove some features that AsciiDoctor had:
1>
)Probably the Markdown compatibility syntax is the most impactful item on the list. You can find more information about the removals here.
From what I’ve gathered the language spec is still a work in progress, but it seems to be shaping up nicely. I’m really glad I finally caught wind of it, so I can also align Emacs’s adoc-mode with it.
That’s all I have for you today. Keep hacking!
]]>One of the shortcomings of Bluesky (for me, at least) is that relatively few people that I know are using it. Almost no one from tech. I guess many people from tech are kind of skeptical of another social network founded by Jack Dorsey, even if it claims that this time things will be different.
Anyways, I decided to give Mastodon another go. To make sure things go differently (better) this time around:
fosstodon.org
and ruby.social
to bbatsov@hachyderm.io.1#Clojure
, #Ruby
, #OCaml
and #Emacs
)Mona
)I was pleasantly surprised how easy it was to forward all my accounts to a single one and to migrate my followers there. Well done, team Mastodon!
I still think that the default UI and UX are far from great, but the real value of every network are the people and the exchanges you have with them.
Mona
is pretty decent on mobile and Mac, sadly no Windows version, but I guess with time I’ll get used to the web UI.2
That’s all I have for you today. I’ll keep using Bluesky and Mastodon for a while and see which one sticks. See you in the Fediverse!
]]>I’m still not happy with the current state of X/Twitter, though, so I kept looking for other alternatives and lately I’ve been playing with Bluesky. I like it for a few reasons:
Bluesky still misses a lot of features I consider important - from basic stuff like bookmarks, to more important things like enough (critical mass of) people using it. Still, it has a nice vibe and I think it has a higher chance to succeed in the long run, compared to Mastodon.
I serious doubt in will really challenge the leading position of X (or even that of Threads), but as long as it attracts enough people to be useful that’d be a big success in my book.
If you’re on Bluesky feel free to ping me. If you haven’t tried it already - it just went public a few days ago, after requiring invites for sign-up for the past year. See you around! Blue skies ahead!
]]>In the end, there can be only one.
– Highlander
I’ve had a problem with email for a while now. It took me a while to recognize how absurd this is, but it finally happened. Using multiple email vendors is major pain in the ass, so I finally decided to clean up shop a little bit.
Ever since I started using Fastmail I pretty much stopped using the other email vendors that I had accounts with. I kept them around for unclear reasons (e.g. maybe they’d introduce some killer new feature or maybe I’d find some use for each of them down the road), but at some point I almost forgot about them and would only be reminded when someone sent me an email using a vendor I don’t really monitor. Needless to say it always took me a while to figure out that something like this had happened.
In the end I’ve decided to kill my Hey and Proton subscriptions and focus entirely on Fastmail. Yeah, I still have accounts with Google, Apple and Microsoft, but I never really use them for email.
Playing with different email services was certainly fun and I did learn a lot from Hey, but it feels nice to have a simpler email setup. Moving on to my next mania!
]]>OCaml 4.03 introduced the @tailcall
attribute which will trigger a compiler warning if it’s not placed at an actual tail-call.1 It should be used like this:
(f [@tailcall]) x y
warns if f x y is not a tail-call
Here are a couple of trivial examples to help illustrate this:
(* tail-recursive factorial function *)
let rec fact1 acc x =
if x <= 1 then acc else (fact1 [@tailcall]) (acc * x) (x - 1)
(* non tail-recursive factorial function *)
let rec fact2 x =
if x <= 1 then 1 else x * (fact2 [@tailcall]) (x - 1)
Save the code above in a file named tailcall.ml
and compile it with ocamlc
:
$ ocamlc tailcall.ml
File "./tailcall.ml", line 5, characters 28-55:
5 | if x <= 1 then 1 else x * (fact2 [@tailcall]) (x - 1)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
Warning 51 [wrong-tailcall-expectation]: expected tailcall
As you can see the compiler properly detected that fact2
is not tail-recursive, as the tail-call is *
instead of fact2
.
Small, but handy feature that helps you ensure your code works the way you intended it to work.
That’s all I have for you today. Keep hacking!
Basically the tail-call is the call that triggers the recursion in the function and for a function to be tail-recursive the last call has to be an invocation of the recursive function itself. ↩
Life can only be understood backwards; but it must be lived forwards.
– Søren Kierkegaard
Another year is behind us and I guess it’s time to write the obligatory year in review post about it.
Note: Here I’ll focus on the personal side of things and won’t go into details about my OSS work. I plan to write a separate summary article about it on “Meta Redux”.
The bad stuff hasn’t really changed much from last year:
On top of this I really lacked inspiration to write, so it was a pretty bad year for blogging.
I hoped that I’d do more conference talks/trips this year, but ended up doing just one (RubyDay in Verona). I had a ticket for the final edition of “Strange Loop”, but the time of the conference was quite inconvenient for me, so at the end of the day I’ve decided to skip it. The prospects for massive changes on this front in 2024 are modest, but I’ll try to attend a few more conferences, starting with Balkan Ruby in April.
Not much to report here - again things haven’t changed much since last year. Same old on the OSS front, less wine (but still plenty) and more travel. And a bit of fun with old-school digital (think Casio) and mechanical watches.
The highlight of the year for me were a couple of vacation trips to Spain and France and a couple of team trips. I finally made it to Burgundy, which is quite the achievement for any wine lover!
The political situation in Bulgaria remains very unstable after the invasion of Ukraine by ruzzia, but it was a bit better in the second part of the year. Our new government is flawed in numerous ways, but it re-affirmed the pro-EU orientation of the country, passed some long overdue reforms and provided a bit of military aid to Ukraine. This certainly provided a bit of respite after what happened here in the second half of 2022 and early 2023.
In December we demolished the infamous monument of soviet occupational army in downtown Sofia, after debating what to do with it for over 30 years. I hated this monument and what it stood for, so seeing it torn down felt pretty good. In the final days of 2023 Bulgaria was admitted in the Schengen space (albeit partially), effective 31st of March, 2024. That was another long-awaited event that I was quite happy about. There are still a lot of problems, but there’s always some hope for the future.
We are what we repeatedly do… therefore excellence is not an act, but a habit.1
– Will Durant
We are what we repeatedly do… Not exactly something new I learned in 2023, but definitely something I was often reminded about.
Also - I have a very obsessive personally and once I set my mind on something I usually go all-in. That’s why people like me should have fewer hobbies, as they often turn into some manias. Oh, well…
And finally - don’t commit to reading long-winded mediocre fantasy series! Seriously!
Haven’t figured them out yet.
Not great, not terrible.
And that’s a wrap. One less item in my person to-do list!
I think the words “not great, not terrible” perfectly describe 2023 for me. I haven’t had a truly great year since 2019 and I often dreaming about the “boring” years without political turmoil, major wars, pandemics and recessions. Now I finally understand why “May you live in interesting times” is a curse.
I hope you’ve had a great 2023 and that 2024 will be even better for you!
]]>In 2023 I lacked the inspiration1 to write and as a result, I’ve written only a handful articles to date. I’ve been pondering this morning what contributed to this lackluster performance and the following reasons came to my mind:
There are still a ton of topics on my backlog that I’d like to write about in the future (e.g. the lessons I’ve learned as a long-time OSS developer/maintainer, updates on OSS projects and some ideas for their future, more musings on Emacs and Lisp), but I’ll get to those when I get to those. If ever. Let’s see if 2024 will be better on this front. Perhaps I find my inspiration every other year!
And the energy that comes with it. ↩