Posts

  • Nov 21, 2020

    Disable global-hl-line-mode for Specific Modes

    A long time ago I suggested the use of global-hl-line-mode for highlighting the current line. There’s one problem with the mode I failed to cover back then - namely how to disable it in certain modes where it doesn’t make sense to highlight the current line (e.g. in REPL or terminal buffers).

    When recently someone asked me how to disable it in vterm-mode I assumed it’d be as easy as:

    ;; doesn't work
(add-hook 'vterm-mode-hook (lambda () (hl-line-mode -1)))

    Unfortunately it turned out that for some reason that doesn’t work. Still, a working solution to our problem is relatively simple:

    (add-hook 'vterm-mode-hook (lambda () (setq-local global-hl-line-mode nil)))

    This example uses a specific major mode as its target, but you can easily target a more common parent mode - e.g. most REPL modes in Emacs derive from comint-mode, so you can do something like:

    (add-hook 'comint-mode-hook (lambda () (setq-local global-hl-line-mode nil)))

    By the way, perhaps it’s better not to use the global mode in the first place and just enable hl-line-mode where it makes sense. I think this configuration should work well for most people:

    ;; let's enable it for all programming major modes
(add-hook 'prog-mode-hook #'hl-line-mode)
;; and for all modes derived from text-mode
(add-hook 'text-mode-hook #'hl-line-mode)

    As the saying goes - less is more.

    That’s all I have for you today. I hope you learned something useful. Keep hacking!

  • 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. ↩

Subscribe via RSS | View Older Posts