RE: delete-selection-mode as default

[Drew Adams]

> This may be your main problem.  The concept of "selection" doesn't really
> exist in Emacs as such.  So your desire for there either positively to be
> a selection or not be a selection at any given time doesn't really make
> sense.  In Emacs there is point and (usually) mark, which delimit the
> region.  If you want to regard the region as being "the selection", you
> can, but if you try to extend that to "there always being a selection",
> you run into conceptual trouble.  That's what I think has been happening,
> here.

Actually, Emacs recognizes and has support for selections: the primary
and secondary selections, if they exist. See (emacs) `Primary Selection'.

But your main point is valid. The Emacs region can make use of or
change the primary selection, but the two are not the same thing.
And users can configure how much they want the region to interact
with the primary selection.

It is in part because of the existence of both the region (point and
mark) and the primary selection that things can get complicated and
users can choose quite different behaviors from each other. This is
all Emacs - there is no one Emacs way when it comes to these things.

But it is true that, however a user might choose to manifest it or
have it behave, there is always the Emacs region (point and mark),
as soon as a buffer has a mark.

Keeping in mind the possible behaviors that other users might
choose can be tricky, partly because we tend to know so well
how "our" Emacs behaves and not so well how "their" Emacs
behaves.

When it comes to discussing what the default behavior should
be, a prerequisite is that we try to learn about and keep in mind
the "other" behaviors. Easier said than done, no doubt.

Hw (and others): The behavior that Alan is describing - the one
he chooses for Emacs, is the original Emacs region behavior.
It is not some crazy, odd, or dangerous thing. It's a perfectly fine,
efficient, and logical behavior. And yes, it is specific to Emacs -
not known much, if at all, outside Emacs. It is no longer the
default behavior, but it was for a long time.

The current default behavior of Emacs wrt the region is what
it is. In a way, I'd characterize it as being between two chairs,
but it is not so bad or uncomfortable. I'd prefer that we turn
on `delete-selection-mode' by default, but it's apparently
already been decided (by RMS and Eli) that that won't
happen just yet. Not a big deal.

----

We might want to consider making more obvious some of
the main user choices regarding region, selection etc. I think
it's not obvious to users, especially new users, what choices
are available. I don't have a concrete suggestion of how we
might do that, but I think there's probably room for
improvement.

The various variables, modes, etc. that control the behavior
are here and there, and their presentation in the docs is also
here and there. Depending on the choices you want, the
notion and behavior of the region can have to do with
cutting and pasting, navigation, acting on a stretch of text,
narrowing, highlighting, mouse selection, and other things.

You'll find some info in the docs under `Cut and Paste',
some under other topics. And that's normal. The region
affects almost everything, and it can behave differently for
different uses and different people.

But maybe there could also be some place where the
modes and options that govern region-related behavior
are discussed together. Dunno. I don't mean repeating
what's said elsewhere in the doc, but somehow bringing
these things together.

A Customize group might be a start, though that wouldn't
really provide an organized presentation of the main
choices/approaches.

Just wondering out loud, I guess. I don't have anything
really to offer about this. I see a problem/opportunity
more than a concrete solution in this regard.

Whoever (Stefan?) suggested providing various high-level
user "profiles" or whatever - behaviors to try on, had a
good idea. For region-related behavior that could perhaps
be as simple as defining some modes or options that
combine existing modes and option values.

If that were done then its presentation in the doc would
maybe correspond to what I suggested (above) is missing.