Shift-Click in Emacs to Select – A Simple Change With a Complex History

Sometimes I actually do wonder why the Emacs defaults are whatever they are.

Someone somewhere decided that clicking with the left mouse button while holding shift should pop up an appearance menu where you can change font size and things like that.

The behavior I expected from my personal history of 25 years or so of using computers is to extend the selection up to the clicked point.

In text buffers, that means: select the text up to there; in a GUI file manager that means I expect to select files from the initial selection up to the clicked file. But not in Emacs, ha!

The change is pretty simple. Luckily, by now I know what functions are usually named in Emacs; it’s nothing with “selection” in it, it has to be “mark” and “set”, and “mouse” as a prefix most likely. And yes, mouse-set-mark exists and works!

So here’s the change I want:

(global-set-key (kbd "S-<down-mouse-1>") #'mouse-set-mark)
;; was: mouse-appearance-menu

Looking for functions that might change the selection, I also found that by default, C-M-<down-mouse-1> allows rectangular selection. Usually, that’s bound to option-dragging in macOS text editors that support this, so I remapped that as well since A-<down-mouse-1> is free:

(global-set-key (kbd "A-<down-mouse-1>") #'mouse-drag-region-rectangle)

But as I wrote at the very beginning, I do wonder why the appearance menu is the default. Is that a recent addition? Or does this precede my birth? Everything’s possible in Emacs.

The mouse.el copyright line says:

;; Copyright (C) 1993-1995, 1999-2022 Free Software Foundation, Inc.

So the addition of mouse input isn’t ancient, but it’s potentially old.

Looking at the code from emacs-mirror on GitHub, we can inspect when the binding was added.

The git blame output of the key binding reveals quite a lot!

  • 30 years ago, JimB added a binding of drag-mouse-1 to mouse-set-region in the vicinity of this line. So drag to select is there since the early days of mouse.el.
  • 14 years ago, then, Chong Yidong added mouse-appearance-menu to Emacs 23 and bound it to [S-down-mouse-1] in this single commit.

Chong Yidong’s commit also does not reveal any deletion of a previous binding.
The decision to bind shift-click to the appearance menu is from Jun 15, 2008. I guess that this binding was free, so they just rolled with it.
So shift-click might just as well have been unbound for all of the 16 years that dragging to select was a thing, it seems. (We’ll see that this isn’t true in a minute.)

But in 2008, shift-click to select was a “thing” for computer users for a decade at least. I’m pretty sure we used this in Windows 95. I never touched a Mac in the 1990’s, but I would imagine that Mac OS with the signature single button mice had this modifier, too.

By 2008, you could easily install Linux distros on home computers, and chances were you already had a fast internet connection to download distros with a graphical desktop environment. KDE 3 was around the corner, GNOME 2 was already 6 years old, and I am somewhat certain that shift-click to select worked as expected, too. At least I don’t remember any surprises there.

Yet the Emacs dev team shipped shift-click to pop up a selection menu to change visual settings. That’s curious.

This binding is weird in 2022, and I argua that it was weird in 2008, too.

It probably was and still is less weird for people using Emacs and their computer in general without mouse input: if it’s irrelevant to you, you don’t know about common conventions, and chances are even if you do know, you don’t care. You can find people who think mouse support in Emacs in 2022 is still unnecessary.

Thanks to the emacs-devel mailing list archive, we can check the discussion from back then to find out more. Chong Yidong opened the discussion thus:

Currently, shift-down-mouse-1 pops up a menu that lets the user choose a
different font to apply to the current frame.

This doesn’t seem like a very useful operation for a mouse binding.

I strongly agree! The supposed change, though, doesn’t make much sense to me, either :)

Now that the face-remapping code has been checked in, I’d suggest
changing this menu to a “buffer faces” menu.

Nobody in the thread pointed out that shift-click selection exists; it wasn’t discarded because it wasn’t even brought up. Maybe nobody really cared? Or did people actually like the binding?

In 2003, it just occurred to Kai Großjohann “that the S-down-mouse-1 font menu should be available in the menu bar somewhere”, which means Chong Yidong improved a binding that was at least 5 years old.

Even in 2001, this already was a thing, another mailing list thread indicates.

So there we are now, 21+ years later.

In 2017, there’s been a suggestion by Tak Kunihiro to remap this to mouse-save-then-kill (which is also a bit weird because it copies the selection automatically), but Eli Zaretskii didn’t like that because it means retraining of muscle memory;

All that just to provide some kind of “consistency”?

(Yes, exactly because of that! :))

There’s not been a lot of discussion on the mailing list with regard to that binding. To cut to the source of things, Richard M. Stallman committed on Aug 31, 1992 a change that unbound shift-clicking in favor of dragging.

It’s been RMS’s fault all along :)

To me, this is a curious piece of Emacs history that makes me wonder who the people on emacs-devel were back then, what the binding was based on (“The current binding of S-mouse-1 was not taken out of thin air, it was modeled on other applications as well, AFAIR”), and what their stance on GUI and mouse input was.

Is this new binding after RMS’s removal a silent rebellion against Windows and Mac and also Linux desktop environment conventions?

Or is it merely an example that some folk simply do not put user experience of normies at the tippety top of their priority lists?

We can only speculate. (Or read the mailing list until we get a feeling for the dramatis personae.)

I don’t want to blame anyone here besides git-blame’ing their code. UX is especially hard to make consistent if there’s no guiding design principle; we see this in FOSS software projects a lot. “Design by committee” is a well-known saying in our industry for a reason.

In my interpretation, this merely reveals priorities. Improve an existing shift-click binding that was limited in its function with a better function. Make things incrementally better through tinkering.

On a much more positive note: we can inspect the Emacs history to find out what was going on, who was involved, and what the reasoning was.

Even if I, in 2022, find the shift-click binding to be weird, for almost 3 decades now people seemed to have a different vision. That’s a humbling revelation. Without the history, I wouldn’t have been able to figure this out, and my gut reaction would have remained – something along the lines of “this must’ve been some neckbeard without a mouse looking for a free key binding to satisfy a feature request on paper without thinking this through, gah!”