[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: delete-selection-mode as default

From: Drew Adams
Subject: RE: delete-selection-mode as default
Date: Sat, 15 Sep 2018 17:22:39 -0700 (PDT)

> You don't need a region for commands to work on, a selection is enough.
> That would allow to decouple navigation from (making) selections, and
> the concept of a region becomes obsolete, removing all the entanglement
> and greatly simplifying things.

In case there are others who, like me, did not completely get this
point from Hw, though he touched on it several times -

My guess is that that is his main point, and it underlies other things
he's touched on. (I could be wrong, and perhaps he will correct me.)

I think this is yet another UI approach that is possible. I don't see
it as in any way combining well with, or affecting, the behaviors
we've been discussing. But it would be possible for someone to
implement it, if someone is interested.

In a sense, we have this already with the secondary selection.
One thing we don't have for the secondary selection are ways
to create or extend it other than using the mouse. (I have some
ways in my library `second-sel.el', but vanilla Emacs has none,
I believe.) That could easily be remedied.

The main thing we don't have, out of the box, for use with the
secondary selection are ways to do what users outside Emacs
often do with a selection: in particular, d-s-m-style things such
as type to replace and delete. That behavior too could be added.

The main way in which the secondary selection does not fit
what users outside Emacs are used to is that it involves the
secondary, not the primary selection. What Hw wants is no
doubt to be able to use the primary selection in these ways.

I mention the secondary selection because it is maybe the
closest thing that Emacs has to what Hw is describing, not
because using the secondary selection for the kind of
behavior he wants is the best approach.

What is it about the secondary selection that makes me
think that it is like what Hw describes? This: unlike the
Emacs region, there is no requirement that either end
of the selection be visible, i.e. on the screen, even when
you act on it. By contrast, by design the Emacs region 
always has the cursor end of the region, i.e., point, on
the screen.

The secondary selection is similar to what you see in
many other applications (browsers etc.): you can select
text with the mouse, that text stays selected, and so
 highlighted, even if it is scrolled completely outside
the visible area of the "page". And regardless of where
it is currently (even offscreen), you can select a different
bit of text somewhere instead (removing the previous

All of that is very much like how other apps treat the
primary selection, I think. Some apps sometimes also let
you type-to-replace the selection. Others do not; they
make you explicitly use a key to cut the selected text.

Dunno whether this comparison helps, but I think it helps
me understand better some of what Hw has been saying.
(Perhaps this was already obvious to others; dunno.)

And maybe it helps Hw understand a bit more about the
Emacs behavior, which absolutely requires that the cursor
end of the region always be visible in the visible part of the

And yes, perhaps that basic Emacs tenet of keeping the
cursor visible is partly rooted in the emphasis Emacs gives
to the keyboard, and in its origin before the widespread
use of pointing devices (mouse).

In that context you pretty much always want the insertion
point (aka text cursor) to be visible. You are not typically
selecting text with a mouse and then acting on it.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]