emacs-devel
[Top][All Lists]
Advanced

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

Re: delete-selection-mode


From: David Kastrup
Subject: Re: delete-selection-mode
Date: Mon, 21 Apr 2008 22:28:50 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

"Lennart Borgman (gmail)" <address@hidden> writes:

> Jason Rumney wrote:
>> Don't mix C-SPC setting of the mark and Shift-movement. Use one or
>> the other.
>
>
> I would actually suggest one mixing:
>
> - If the user activated the region with Shift-movement and then types
> C-SPC then keep the current active region, but switch to the C-SPC
> semantics for the current active region (ie arrow keys should not
> deactivate the region).

Anyway, we have at least three active region semantics in Emacs' default
behavior:

a) semi-traditional transient-mark-mode (with mark-even-if-inactive)
b) temporary transient-mark-mode triggered by mouse commands
c) whatever transient-mark-mode triggered by shift-movement

It turns out that (b) and (c), for some reason, can extend a region set
by each other, while (a) can't.

However, you can extend a region set with (a) with a (b) type mouse
command (right click to extend region).  You can't extend (a) using (c).
For a region selected with (b), hitting DEL will erase the region.  This
is not the case for either (a) or (c).

This is pretty much an incoherent mess.  Since the objective was to have
a "newbie-mode", I propose that we at the very least fold (b) and (c)
into a single mode.

This implies that hitting DEL after either (b) or (c) style marking
should delete the region.

For this single mode, we might want to have the equivalent of
delete-selection-mode available (possibly by default, but at the very
least optional): erasing an active region selection by one of the two
"well-known/newbie/industry-standard" methods (b) and (c) when a
self-inserting character is typed.

Note that I am talking about a consolidated _default_ behavior of Emacs
here.  It is not clear to me which of the multitude of existing mode
variables should actually be retained.  I don't think it realistic to
get coherent behavior for all combinations of existing and necessary new
mode variable settings.  At the very least, I think that the exact
current semantics of temporary-transient-mark-mode in connection with
mouse commands is not worth trying to preserve with some setting
combination in the course of this cleanup.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum




reply via email to

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