The Most Controversial Change In Emacs History

Just a scant handful of decades after XEmacs introduced a mode line with proportional fonts, we’re thinking about doing the same in Emacs.

Here’s how the mode line looks (by default) in Emacs 28:

Here’s how we’re considering having it look (by default) in Emacs 29:

See? Huge difference. Huge.

The attractive thing about this change is that, well, it’s prettier, but it’s also more consistent with the other elements at the margins of the Emacs frame: The menus and the toolbar have used proportional fonts for a long time, so doing the same in the mode line might also be nice. And you can generally squeeze in more information when using proportional fonts, which is helpful if you’re jamming a lot of stuff into the mode line:

Changing this has been brought up a number of times over the years, but there’s been pushback because some of the elements in the mode line are pretty dynamic, and it’d suck if everything moved around. For instance, when displaying the column number in the mode line, it might be annoying to have the rest of the line shift to the left/right when moving the cursor around in the window.

So we’ve now added a new display spec (called ‘min-width’) today that you can slap around bits of text (and in the mode line) that ensures that the width never decreases beyond a certain point.

Perhaps that’ll make a difference in the level of resistance? I guess we’ll find out, because starting today, we’re doing a one month long test on “master”: This new mode line look is enabled by default now, and in a month we’ll evaluate based on feedback.

So give it a whirl for a few weeks, and vote on emacs-devel mailing list. (And report any glitches, of course. And suggestions for improvements are always welcome.)

11 thoughts on “The Most Controversial Change In Emacs History”

  1. Hey Lars,

    Personally I like fixed width and not variable width, so I don’t think it’s prettier.
    I also don’t care about consistency with the menu or toolbar, because I have them disabled.
    I don’t know if it should be the default or not, but I do know that I’ll turn it off after installing a new emacs version and noticing that something’s wrong.
    In general I like and appreciate your work (thanks!), but I don’t like UI changes (in any software).
    Every time someone on emacs-devel talks about changing this or that default in the UI department (and sometimes other departments) I get a bit worried.
    Often that comes with appeal to newbies or some imaginary population that’s just waiting to use emacs but won’t do so as long as some particular 30 years old decision bit is not flipped.
    But I’m just another emacs user.
    Again, thank you for your work.

  2. Is the new default font taller than the old?

    I think I’ll try setting the echo-area font to a variable-pitch one as well, it looks a little jarring when it’s different font.

    Why is the default background color of the modeline so dark, by the way?

    1. Should be the same size, but it depends on what fonts you have installed, really. And perhaps there should be a dedicated face for the echo area/minibuffer?

  3. Ok, so by searching I’ve found that if I a) customize the minibuffer-prompt face and also go:

    (buf (list ” *Minibuf-0*” ” *Minibuf-1*” ” *Echo Area 0*” ” *Echo Area 1*”))
    (when (get-buffer buf)
    (with-current-buffer buf
    (setq-local face-remapping-alist ‘((default (:inherit variable-pitch)))))))

    Then I almost get the variable width font there – except for the text I type in myself, e.g. after pressing M-x. I wonder how to get that variable width as well…

  4. Ok, got that last part solved by searching some more:

    (defun my-minibuffer-setup-hook ()
    (buffer-face-set ‘variable-pitch))
    (add-hook ‘minibuffer-setup-hook ‘my-minibuffer-setup-hook)

  5. > Should be the same size, but it depends on what fonts you have installed, really.

    Ok, I guess the difference is because I have customized variable-pitch to be larger than whateveritwasusingbeforedefaultorsomething. ๐Ÿ‘

  6. There are lots of configs that use string-width to dynamically position sub-parts of the mode line (left/right align, for example). To support updated versions of these, there would need to be a better alternative to window-text-pixel-size, which requires a live window, to pre-compute pixel widths of displayed text.

Leave a Reply