Posts

  • Oct 22, 2020

    State of Emacs Survey

    Recently I learned of the first-ever State of Emacs survey and I wanted to share a few thought about it with my readers. Okay, the survey is officially named just “Emacs Survey”, but it clearly draws a lot of inspiration from the numerous “State of Technology X” surveys that have become popular in recent years. That’s why I took the liberty to re-frame it in a way that will probably be familiar to more people.

    The “State of Something” surveys are typically ran by the teams maintaining some project to assess the health of its ecosystem, the needs of their users, the problems that need to be solved, the tools that people are using and so on. A good example would be the State of Clojure, that I participate in every year. There are similar surveys for many programming languages and even for some tools - e.g. I ran in the past a State of CIDER survey.1 Ideally, the data collected from the surveys drives the future development to some extent, and results in a better experience for everyone involved. I can speak from experience that the “State of Clojure” and “State of CIDER” surveys definitely influenced the direction of the projects.

    The “State of Emacs” survey is a somewhat different, though. One thing that bothers me a bit about the Emacs survey is that its site doesn’t list any clear purpose/goals for the survey. That definitely seems pretty weird to me. I saw the survey discussed on the Emacs mailing list and on Reddit, but sticking a paragraph of rationale on the survey site would have certainly helped. The survey is also not official in the sense, that it’s not initiated by Emacs’s development team, and judging by the hostility the topic generated on the emacs-devel mailing list it’s not like they were particularly excited about it.2 It was funny that most of the comments were complaints about things like the use of non-free JavaScript in the survey form and topics like that, instead of some constructive conversation about the format of the survey. I was especially upset about the hostility towards the amazing MELPA project on the mailing list (in his typical style RMS even wanted MELPA to be denounced in the survey, as he considers it evil). Implying that it’d be easy to replace MELPA with some core Emacs repository is like a bad joke, given how the deficiencies of GNU ELPA were the reason for the rise of MELPA in the first place. Anyways, I’m digressing.

    Despite of all my concerns, I hope that the survey be a success in the sense that it will collect enough useful data points to influence the future development roadmap of Emacs and align better the vision of Emacs’s maintainers with the needs and the usage patterns of their users. I’ve already filled out the survey myself and I liked the questions in it, although, I would have definitely structured it somewhat differently. I see some constant trend to compare stuff in Emacs with external packages (e.g. Magit vs vc, Flycheck vs Flymake, Projectile vs project.el), which I find slightly bizarre given the trend in Emacs to move as many built-in packages as possible to GNU ELPA, and the fact that Emacs has always been about diversity of solutions, picking whatever works best for you and so on. Standardization efforts seems somewhat against the spirit of Emacs, but that’s just my very personal take.3

    In case someone is curious about my Emacs wish list - I don’t really care about changing any defaults, package improvements or anything like this. I’d like to see more efforts for improving Emacs Lisp, the standard library (libraries like seq.el and map.el were great additions IMO), making it possible to build rich UIs in some sane manner (overlays are quite limiting). I’d also love to see the bar to contributing to be lowered:

    • drop the contributor agreement
    • discuss ideas in an (modern) issue tracker, instead of on a mailing list
    • apply less political activism and more pragmatism in the conversation around new ideas/features4

    I doubt anything like this is going to happen any time soon, but one can dream, right?

    Finally, I’m obviously curious how my own Emacs Prelude and my packages like Projectile, crux and so on will fare in the survey. Are Zenburn and Solarized still the most popular color themes out there? You tell me! :-)

    Big thanks to Adrien Brochard for undertaking this daunting task and creating the “State of Emacs” survey! It will be open until the end of November. You can fill out the survey form directly here. Share your perspective!

    Update You might also want to check this follow-up discussion, triggered by my article.

    1. CIDER is a personal project of mine. ↩

    2. That being said, way too many topics generate unwarranted hostility there. ↩

    3. Some degree of standardization is not a bad thing, though. ↩

    4. And in decision-making in general. ↩

  • Sep 23, 2020

    Using Emacs on Windows with WSL2

    I don’t know about you, but I’ve never been able to work productively on Windows in the past. Probably because my work requires a lot of Unix tools and libraries, probably because of the absence of certain Unix utilities Emacs wasn’t as useful on Windows (e.g. ls powers dired, many Emacs commands shell out to tools like grep, ag, git, etc).

    In recent years, however, Microsoft has been trying to make amends with the broader developer community in the form of the Windows Subsystem for Linux (WSL). WSL is a fancy way of calling their native VM-like functionality that allows you to run easily Linux within Windows. Microsoft also created a powerful terminal application called Windows Terminal (naming is hard!) that is actually capable of running Emacs in text mode (and it does so quite well).

    One practical problem with WSL, however, is that you can’t really leverage any of the Linux tools from native Windows apps (unless you’re using VS Code, that has some special support for this). If you have a native Windows Emacs installed the only way it can interact with the Linux VM is via TRAMP or some similar tool.

    Turns out, however, you don’t really need to do this, as it’s quite simple to run a GUI Emacs frame from your Linux installation inside Windows. All you need to make this happen is an X server. There are several options around, but I went with X410 as it had the simplest setup and the broadest feature set. Yeah, yeah - it’s proprietary, it’s paid, but it gets the job done really well. As far as I’m concerned those are 10 EUR very well spent.

    So, time for the step by step guide:

    • Setup WSL2 as documented here (don’t forget to enable Virtualization support from your CPU from your BIOS). This guide also covers installing Windows Terminal and some Linux distro. I’ll assume you went with Ubuntu 20.04.
    • Install X410 from the Microsoft Store and start it.
    • Allow public access in X410’s settings panel (it’s in the systray, that’s something I didn’t notice at first). Technically speaking, you’re punching a hole in your Windows firewall by doing this (you’ll be prompted by it to approve this), so be careful on public networks like those at airports. My Windows computer is a desktop on a secure home network, so that’s not really a concern for me.
    • Add this to your .bashrc:
    export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2; exit;}'):0.0
    • Reload your .bashrc using source .bashrc.
    • Start Emacs from a WSL terminal with emacs &.

    At this point an Emacs frame will appear on your Windows desktop. It will have an icon in the Windows task bar and will feel like any other Windows app. Appearances are deceiving, however, as it actually runs inside your Ubuntu VM. I have to admit I was shocked how easy this was and how well it worked, even though running GUI apps over X is not officially supported by WSL (at least not yet).

    A note for HiDPI display owners - HiDPI scaling didn’t work properly for me (despite setting GDK_SCALE to 2 in my .bashrc) and the text in Emacs was tiny at first, but that was easy to address - just double your default font-size in Emacs (assuming you went with scaling factor of 2 (200%) in Windows). I went for the following addition to my Emacs config:

    ;; the default font size was 14
(set-frame-font "DejaVu Sans Mono 28")

    Perhaps there are better way to handle this, but that gets the job done. I tried some HiDPI scaling options in X410, but the results were somewhat blurry, so I prefer my simple approach which resulted in crisp and sharp text. Check out X410’s documentation on HiDPI for more details.

    One small annoyance to keep in mind is that putting your computer to sleep will kill your Emacs GUI frame. From what I got that’s a limitation of WSL2 that can’t be circumvented for now.

    Also note that systemd doesn’t work on WSL2, so you won’t be able to use it to start Emacs in daemon mode, as discussed here. Not a big deal, by any means, just something to keep in mind.

    If you run into any problems with this setup, check out X410’s excellent documentation. That’s the only resource I needed.

    If you feel strongly against paying for X410 there are some other X server options that you can consider:

    I haven’t tried them, however, so I can’t comment on how good they are. If you’re running Emacs using some other X server for Windows, please share your experience in the comments.

    And that’s a wrap for today. I’m happy to report that Windows has never been a better option for Emacs users, and developers in general, than it is today. This post was authored in Emacs running on WSL2, and there’s a high chance I’ll keep using Windows and WSL2 for the foreseeable future.1 Keep hacking!

    P.S. After writing this article I learned that soon you’ll be able run Linux GUI apps in WSL out-of-the-box! Check out this article for more details.

    1. My intention was to use Linux directly, but some unfortunate driver issues with my GPU (Radeon RX 5500 XT) forced me to switch to Windows 10 for now. Once again I was reminded it’s unwise to buy recent hardware and expect it to work properly with Linux. Better luck next time! ↩

  • 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!

Subscribe via RSS | View Older Posts