If you enable Delete Selection mode, a minor mode, then inserting text while the mark is active causes the selected text to be deleted first. This also deactivates the mark. Many graphical applications follow this convention, but Emacs does not.


Why? What kind of Emacs workflow is advantageous in not having this as a default?


I've argued the same thing for a long time: delete-selection-mode should be turned on by default. I argued for turning on transient-mark-mode by default, and after decades that eventually happened.

The main reason delete-selection-mode is not on by default is inertia, aka tradition, I think. It is expected by most users of editors and other applications today, but when it was introduced to Emacs it was seen as pollution from the Microsoft Windows world and perhaps as something dumbed-down.

The main "technical" reason I've seen given for it is that some people who are not used to it have found that they accidentally deleted or replaced text. That's pretty much a non-reason ("I'm not used to it."), IMO. The only other "technical" reason I've heard is that it saves you only a C-w - IOW, if you want to delete the selected text all you need to do is hit C-w. (That's true, of course.)

If you want to argue in favor of delete-selection-mode as the default behavior, emacs-devel@gnu.org is the place to propose such a change.

  • I'm not that familiar with the Emacs ecosystem, but wouldn't Spacemacs be an easier place to get the ball moving in this direction? – m33lky Apr 17 '17 at 20:30
  • I disagree. First, any feature that quickly and automatically destroys text is a bad idea from the beginning. Seoncd, breaking the user habits of basically all long-time Emacs users is not also not great idea. Emacs has never been Windows, CUA or OSX compliant. Trying to make it such begins a slippery slope. If you want a special behavior, customize it yourself. That's the emacs way. – kmarsh Nov 20 '17 at 13:39
  • 2
    @kmarsh: The exact same thing was said for decades, over and over, about transient-mark-mode. Finally we got that turned on by default. Turning on both transient-mark-mode mode and delete-selection-mode by default would be a good thing, not a bad thing. I have no doubt that eventually the latter will happen too, but it might take another 30 years. ;-) Oh, and this has nothing to do with Windows. Oh, and I am not in favor of turning on cua-mode by default. – Drew Nov 20 '17 at 16:15
  • @Drew we'll have to disagree on this one. I have more fully elaborated my position in a new answer, below. tl;dr Productive work flows already exist, new default text-destroying changes are bad. The ONLY driving reason for this default to change is "works more like Windows". – kmarsh Nov 20 '17 at 16:18
  • 2
    There are nothing wrong with features that quickly destroy text. That's why we have undo. Destroyed text can be brought back as quickly as it went. – Cthutu Feb 15 '19 at 14:03

It's possible to use your keys much more efficiently when the mark is active than simply binding all of them to delete the region.

lispy is a nice example of this:

  • When the region is active, all keys a through z are bound to different commands.
  • When the region isn't active, all keys a through z self-insert.

Here's a simple example:

 (kbd "d")
 (lambda (arg)
   (interactive "p")
   (if (region-active-p)
     (self-insert-command arg))))
 (kbd "w")
 (lambda (arg)
   (interactive "p")
   (if (region-active-p)
       (call-interactively 'kill-ring-save)
     (self-insert-command arg))))
 (kbd "c")
 (lambda (arg)
   (interactive "p")
   (if (region-active-p)
       (let ((str (buffer-substring-no-properties
         (goto-char (region-end))
         (insert "\n" str))
     (self-insert-command arg))))

Now your d, w and c do all kinds of different useful things, instead of simply deleting the region.

  • I'm sorry but lispy appears to follow vi's conventions which is contrary to Emacs ones. – m33lky Apr 19 '17 at 6:53
  • 1
    OK then, nevermind. – abo-abo Apr 19 '17 at 7:54
  • I meant this in relation to the question. Maybe there are other situations where people actually want to keep the selection active. – m33lky Apr 19 '17 at 11:42

Perhaps a better question is, will changing the default result in a better Emacs? Any change which auto-destroys text, the very thing we entrust to Emacs, should be regarded with extreme caution. For example, how many newbie users have experienced a sudden highlight all/one key stroke/everything is gone event? I've seen it happen over and over again. The rage, frustration, disbelief is palpable. Why invite that experience into Emacs? Is that really better?

Making Emacs work like Windows is not a valid argument. Emacs can never work like CUA (Common User Access) and still be fully useful (and still be Emacs). There is a CUA mode for Emacs, it's not very popular because it overrides so much of what makes Emacs work like Emacs. Emacs is keyboard driven and fixed font width text oriented. Windows is mouse driven and WYSIWYG oriented.

Emacs predates Windows. Forcing every experienced Emacs user (destroy text, rage quit, then) undo a new default goes against more than culture, it begs the question, why even use Emacs? For the configurability? Then turn on the delete-selection-mode in the configuration yourself.

But to answer the question, there are many, many workflows, with the primary commonality that they are keyboard driven, not mouse driven. Here is but one, all done with the keyboard, no mouse required. I do this workflow every day, many times a day, while writing code and editing data. It is simply bringing a few lines from another point in a file and then continuing composition.

Set point near desired text
Move Point, highlighting text 
Cut or Copy
Move Point 
Exchange Point and mark, moving to end of pasted text 
Continue text entry after highlighted region (oops all the pasted text is gone!)
  • 1
    The behavior provided by delete-selection-mode has nothing per se to do with MS Windows, and nothing to do with using a mouse. It comes down to which one finds more convenient with the region active: hitting C-w and then typing replacement text or just typing replacement text. Both behaviors are useful and each is preferred by some users. Just like the use of transient-mark-mode: there are plenty of Emacs users who got tripped up when that was turned on by default. And there are good use cases for turning it off. – Drew Nov 20 '17 at 20:25
  • I've been observing myself using Emacs today... constantly unselecting text to prevent replacement would add an additional keychord to just about everything I do. It would be a huge drag on my productivity, and the first thing I would customize away. Even if you think it has nothing to do with Windows (or GUI's in general)... it has EVERYTHING to do with increasing the odds of unwanted destruction of text. – kmarsh Nov 21 '17 at 0:03
  • After 3 years, and another downvote comes in... and NO discussion of my post issues here, just quibbling about whether it's Windows behavior or begging the question. The sudden destruction of highlighted data is a very real problem. Changing core Emacs behavior is a big challenge for the entire user base. Anyone downvoting should explain why by addressing these points, it is an expected StackExchange courtesy. – kmarsh Jul 31 '20 at 13:54
  • @kmarsh - every other program on Windows or macOS behaves with delete selection on. I use lispy in emacs and the number of times I get a beep or random things happen when I type having a selection is overwhelmingly usual. I have had to stop using the package as this behaviour is so unusual having used other apps for 30 years. Basically going against consistent OS based behaviour is a loss of time. Yes I use an OS and emacs is one of my tools, it is not my main environment. – mmmmmm Dec 7 '20 at 12:29
  • Emacs well predates Windows and MacOS. Introducing a data-destroying feature in the primary modes and conflicting with the muscle memory of every existing Emacs user is just not a good idea. Make it a minor mode and optionally load it. I also have decades of experience and I can tell you one thing for certain, the sequence of highlight-all replace-all in Windows and MacOS has created many, many headaches for many users. Backing it into an existing paradigm where it is unwanted/unneeded is just not a good idea. – kmarsh Dec 7 '20 at 14:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.