Emacs Prelude 1.0 I’ve got a big news to share with you today - after (over) 9 years of development, Emacs Prelude finally made it to version 1.0! There’s nothing really big or groundbreaking there, as Prelude has been in a pretty good place for a very long time feature-wise, but I felt like tagging a 1.0 release, because it’s 2020 and all sort of crazy things are happening the entire year. Most of you probably don’t know this, but Prelude was one of my first open-source projects, that’s why making it to 1.0 means a great deal to me. Open-source projects are a product of love, plain and simple. I know that Prelude has probably lost some of its significance in the era of Spacemacs, Doom Emacs, and a myriad other great Emacs distributions with more features, sophisticated plugin systems, bells, whistles, kitchen sinks, and all that jazz, but I don’t really care. I’m happy that we made it so far, I’m glad that Prelude was the gateway to Emacs for many people, I’m proud of the community we’ve built, I’m proud that it inspired many other distributions to go in different directions, and I’m proud that Prelude always stood true to its core philosophy: simple

easy to understand and extend

stable

a foundation for you to build upon, as opposed to some end-user product that you’re supposed to use as-is This means that it intentionally doesn’t pack all the bells and whistles that it could. Prelude aims to enhance the classic Emacs experience without deviating a lot from it - e.g. it would never enable something like evil-mode (vim keybindings) by default and so on. All the third-party packages that it bundles are carefully vetted and are known to be of good quality and to have reliable maintainers. That generally means that Prelude’s unlikely to immediate adopt some shiny new package, that has established tried and true alternatives. I know some people were pissed/disappointed that in recent years Prelude didn’t change much, but for me this was never a problem - it was actually a feature, in the same way that stability is a feature for Clojure. Fewer changes mean fewer breakages, fewer things to learn, fewer confused users, etc. They also mean that I believe that in terms of functionality and experience Prelude is where I want it to be. Believe it or not, from time to time software projects are (mostly) done. Yeah, there’s always some room for more improvements, but after a certain point the return on investment is simply not worth it (or even worse - it becomes negative). I’m always amused by how many people come to CIDER’s issue tracker reporting basic issues with packages like sayid and clj-refactor (CIDER plugins) that were automatically installed and enabled by their distribution. Most casual CIDER users don’t need those packages and the complexity that comes with them, and power users can obviously install and configure the packages themselves. That’s not a good user experience in my book, and it’s a classic example of the power of the “less is more” philosophy. Prelude bundles only CIDER (no extensions) and it just works. Same with many other programming languages. Rest assured that Prelude will continue to evolve in the future, but don’t expect anything massive to change. Lately I’ve been pondering switching to use-package for the internals, although I don’t see a strong reason to do so, and to leverage more of LSP here and there. Leveraging some Emacs 27 features is also on the agenda. Better documentation would be an awesome improvement as well! One thing I’ve vowed to do going forward is to keep a better track of changes and to tag releases more often. As a result the project finally has a changelog and better contribution templates. I plan (hope) to cut a couple of “stable” releases 2-3 times a year. I also plan to find a couple of co-maintainers to ensure I can retire quietly down the road, but I’m in no rush to do this. I guess that was one pretty weird release announcement, but that’s the release announcement I felt like writing. Thanks to everyone who helped and used Prelude for almost a decade! I love you all! Keep hacking!

Describe Package I don’t know about you, but I often need to see some information about a package - e.g. the version I’ve installed, what the package dependencies are, its homepage, the latest available version, etc. While there are numerous ways to do this in Emacs (e.g. using find-library or using package-list-packages ), I definitely believe there’s one command that provides better experience than all the other options - namely describe-package . So, what makes this command so great? First of all - it has a convenient default keybinding ( C-h P ). Another nice benefit is that the command will prompt you for the package to describe, regardless of whether it’s installed or not. This means you don’t really need to know the exact name of the package you’re looking for. Last, but not least, you’ll get a nice little summary buffer from which you can also install or delete a package. Here’s how that buffer looks for my beloved CIDER package: As you can see, all the important package information is there. One really nice touch is that for installed packages you also see their latest available version. It seems I haven’t updated CIDER in month! I guess I know what I’ll be doing after publishing this article. That’s all I have for you today! Keep hacking!

Patronage Revisited A long time ago I wrote an article about my experiment to get some patronage (funding) for my Emacs work via Gratipay. The idea behind the service was simple - lots of small patrons (sponsors) can make a big difference for a creator and their projects (e.g. 500 people donating $5/month). That particular service quickly failed, but today there are many other services like it out there, and I’ll cover here the few I like and I’m currently using. One main issue with patronage services is that they typically take a sizable cut of your earnings/donations, with the famous Patreon being the classic example (5-12% depending on your plan there). On top of their default cut such services might also add extra fees to wire you the money you’ve gathered via their platform. I get that they are running a business, not some charity, but it still stings a bit. That’s why I was extremely happy when GitHub launched their GitHub Sponsors service, where you get every dime that was donated to you. I’ve never been fond of Microsoft, but with their deep pockets I guess they are one of the few companies that can operate a venture like this at a loss for the sake of getting some goodwill from the broader developer community. Needless to say that today GitHub Sponsors is my preferred patronage service. If you’re considering becoming a patron of my work I’d recommend doing so via GitHub. Still, GitHub Sponsors has the downside of being linked to GitHub accounts, and I realize well enough that not everyone has/wants one. That’s why I’ve selected ko-fi and Paypal, as my backup patronage options. I still maintain a Patreon account as well, but I definitely don’t like them as much due to the service fees cited above. With ko-fi there are no fees and with Paypal I believe there are no fees as well, as long as you’re both Paypal users. So, to wrap it up, if you like my writings here and my work on Emacs projects like: Prelude - An Emacs distribution built on top of GNU Emacs 24

Projectile - Project Interaction Library for Emacs, that stays out of your way

clojure-mode - A major mode for programming in Clojure

cider - A Clojure programming environment for Emacs

inf-clojure - Simple interactions with a Clojure REPL

guru-mode - An annoying companion on your journey to Emacs mastery

crux - A collection of useful extensions for Emacs

rubocop-emacs - Emacs integration for RuboCop

zenburn-emacs - The Zenburn color theme, ported to Emacs

solarized-emacs - The Solarized color theme, ported to Emacs Please, consider supporting my work at one of the following patronage services: GitHub Sponsors ( recommended )

) ko-fi

Paypal

Patreon Note that CIDER also has an Open Collective, which you might consider supporting instead of me directly. I recall a few people asked me in the past how will donations help me work more on my OSS projects, provided I already have a full-time job. Obviously, until donations become sizable their main impact would be showing some appreciation for my efforts and keeping me motivated to spend my free time working on OSS, rather than binge-watching TV shows or spending more time with my family and friends. A bit of extra cash can also help with: hosting expenses

hardware expenses (e.g. getting gear needed for development/testing purposes)

travel expenses for conferences related to my projects

unpaid leave from work to focus on some project(s) Long-term my big dream has always been to accumulate enough backing to be able to work full-time on open-source projects, but whether I’ll achieve this dream or not is entirely up to you. That’s all I have for you today. Thanks for your support!

Reinstalling Emacs Packages From time to time you might run into issues with packages that are not properly byte-compiled when installed via package.el (and use-package by association). This may manifest itself in many different ways - typically something being nil /undefined when it shouldn’t be. Here’s a small utility that might help you in such situations: ( defun er-reinstall-package ( pkg ) ( unload-feature pkg ) ( package-reinstall pkg ) ( require pkg )) I hope you’ll agree that the function’s definition is pretty self-explanatory. Now you can do things like: ;; try running this code in ielm or a scratch buffer ( er-reinstall-package 'crux ) ( er-reinstall-package 'projectile ) As one reader suggested we can make the function a bit more user friendly by making it an interactive command that you can invoke with M-x : ( defun er-reinstall-package ( pkg ) ( interactive ( list ( intern ( completing-read "Reinstall package: " ( mapcar #' car package-alist ))))) ( unload-feature pkg ) ( package-reinstall pkg ) ( require pkg )) Now you’ll also get prompted for the package to reinstall with some convenient completion. I assume that’s not a function you’d need often, but it might come in handy from time to time. That’s all I have for you today. Keep hacking!