RE: delete-selection-mode

[Drew Adams]

> > How about starting with delete-selection-mode (regardless 
> > of whether it would become the default behavior - let's
> > assume not, here), and trying to improve it
> > so that it plays better with your use cases?
> 
> I think the only way to have the feature and leave everyone mildly
> happy is to separate the ``deletable'' selection from the normal Emacs
> region.  That is, introduce a new notion, let's call it ``selection'',
> that is a portion of text which is defined by dragging the mouse or
> moving the cursor with the Shift key pressed.  Let then this
> ``selection'' be deleted as in other GUI apps.  This is what newcomers
> expect, they don't know about the region, so won't expect it to behave
> like ``selection''.
> 
> Keeping our hands off the region will avoid the risk of infuriating
> long time Emacs users.

I'm one such long-time Emacs user. And I'm not so concerned about newcomers and
what they might be used to - we have CUA for that. As I said, this is not about
the default behavior, so no one should feel threatened about imposition. That
question should remain open - we can return to what we had as default in Emacs
21 for all I care.

I'm interested here not in newbie-soothing but in making the alternatives
better, as David suggested. I think that delete-selection mode could become the
basis of something that most Emacs users (including most old-timers) would
prefer.

I think we can do better, but I don't have a concrete suggestion, partly because
I don't have a good feel for the use cases and perceived problems.

FWIW, I would never use a selection such as you describe. That's not what is
available with delete-selection mode. I want to be able, when I want, to use the
_region_ in delete-selection ways: delete or type to replace.

We can determine contexts when that is not desirable, and exclude them. We can
provide user options for customization. The problem, as I see it, is not that
delete-selection deletes or replaces the region. It is that it sometimes does so
when someone doesn't want it to.

To me, the starting point for a superior Emacs notion of active area that is
visible, deletable, killable, and replaceable should be the _region_, because of
all of the other wonderful region properties that Emacs offers. 

I _like_ the fact that delete-selection mode uses the region. I take advantage
of that all the time. That's why I suggest starting with it - it is a concept
and behavior made for Emacs, not for merely respecting some non-Emacs
conventions. I think I understand David's concerns, at least generally, and I
suspect we could address them.

I don't see a fundamental contradiction between the notion of Emacs region and a
behavior of sometimes having the region be deleted or replaced by text that you
type. The problem, as I hear it, is that there are other times when you don't
want that to happen. So let's characterize those patterns.

It's likely that after improving delete-selection mode to take such things into
account, different users will want to use it differently. I might want to have
type-to-replace in some of the contexts where David does not want that. Users
should be able to customize the behavior, obviously. 

But the basic infrastructure is what we should start with and improve first. If
properties on command symbols is too simplistic for the kind of control needed,
then let's discover what we really need and make the infrastructure satisfy it.

> It will also avoid the need to produce some
> kind of heuristics for figuring out issues like this one:
> 
> > For example, you say that you don't want to delete the active
> > region sometimes when you type text. Never? Sometimes? When?
> > Maybe you can characterize the use cases better (to yourself
> > at least).
> 
> I feel that any such heuristics, even if we succeed in coming up with
> it, will be a hopelessly fragile pile of twisted little passages all
> alike, that will break on us all the time and cause infinite
> maintenance headaches.

Such a foreboding prospect - you certainly know how to scare.

It sounds like you're giving up before the first shadow of a characterization
has been attempted, throwing up your hands at the first complaint that
delete-selection mode deleted the region when someone didn't want that.

We have lots of code in Emacs that deals with various contexts or conditions.
It's not as if the delete-selection code was already complex. It's rudimentary.
How do you know that a few healthy tweaks might not take care of the main
problems some people encounter?

I'm the first one to argue against complex DWIM attempts - you've heard me
before about that (quitting view mode, combined behaviors for TAB, etc.) - I am
not a great fan of DWIM. In this case, however, I suspect that there might not
be a lot needed, to take care of the perceived problems. I could be wrong. You,
on the other hand, foresee a nightmare. But how to know without at least trying,
taking a look at the existing code?