Posts

  • Sep 15, 2020

    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 projects1, 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!2

    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!

    1. Projectile was the very first one. ↩

    2. Did you notice that Prelude has a docs site? ↩

  • Sep 13, 2020

    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).1 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:

    describe-pkg.png

    As you can see, all the important package information is there.2 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!

    1. I typically bind find-library to C-h l, as I use that one quite often as well. ↩

    2. Most of it is extracted from the package front-matter. ↩

  • Sep 13, 2020

    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:

    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!

  • Sep 12, 2020

    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!

  • Aug 13, 2020

    Emacs 27.1

    The long wait is over!1 Emacs 27.1 was finally released a couple of days ago! Like every major Emacs release, 27.1 packs a lot of new features. Here are the highlights from the official release announcement, with a bit extra of commentary by me:

    • Built-in support for arbitrary-size integers
    • Text shaping with HarfBuzz
    • Native support for JSON parsing (via the Jansson library)
    • Better support for Cairo drawing (I guess I picked a good time to switch back to Linux)
    • Portable dumping used instead of unexec
    • Support for XDG conventions for init files (you can now place your init file(s) in $XDG_CONFIG_HOME/emacs/)
    • Additional early-init initialization file (early-init.el that gets loaded before init.el)
    • Lexical-binding is used by default (after being introduced first in Emacs 24.1)
    • Built-in support for tab bar and tab-line (I’ll write more about those later)
    • Support for resizing and rotating of images without ImageMagick

    Personally, I feel that the native JSON parsing will probably have the biggest practical impact for most people - especially those using lsp-mode or eglot. LSP support in Emacs was problematic for a while now due to the poor performance of the JSON parsers written in Emacs Lisp. I’m pretty sure that the need for better LSP performance was the biggest reason for adding native JSON parsing to Emacs. I don’t use LSP (yet)2, so for me that addition doesn’t mean much, but I know it’s going to have a powerful impact for many people. Seeing how VS Code has quickly risen to the top of the editor market share rankings, it’s clear that the only way to effectively compete with it, is to leverage its own LSP infrastructure. Exciting times ahead!

    All the other improvements in Emacs 27.1 are nice, but there’s nothing that I’m particularly excited about. I’m curious about the practical benefits of adopting HarfBuzz and surprised about the tab bar and tab-line features, but I didn’t eagerly await them. Still, it’s nice that Emacs 27 is out and that the team can now focus on Emacs 28 and native code compilation with GCC. That’s something I’m truly thrilled about!

    As usual - there are many more (smaller) changes in Emacs 27; for a summary see the etc/NEWS file, which you can view from Emacs with C-h n.3 In the next few weeks (months?) I plan to write a few blog posts covering some of the improvements in Emacs 27 in more details.

    That’s all I have for you today! In Meta-x we trust!

    1. Emacs 26.1 was released way back - on the 28th of May, 2018. ↩

    2. Fortunately for me, most of the programming I do is in Emacs Lisp and Clojure. ↩

    3. https://www.gnu.org/savannah-checkouts/gnu/emacs/news/NEWS.27.1 ↩

Subscribe via RSS | View Older Posts