emacs-devel
[Top][All Lists]
Advanced

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

Re: delete-selection-mode as default


From: Eli Zaretskii
Subject: Re: delete-selection-mode as default
Date: Tue, 18 Sep 2018 15:14:26 +0300

> From: hw <address@hidden>
> Cc: address@hidden,  address@hidden,  address@hidden,  address@hidden,  
> address@hidden,  address@hidden,  address@hidden,  address@hidden
> Date: Mon, 17 Sep 2018 23:22:04 +0200
> 
> >> Emacs has point and (the end of) the region (selection) always entangled
> >> with no way to separate them or to disable the region.  That is what I
> >> dislike so much, and it causes all kinds of issues.
> >
> > It is also why it is so convenient to define the region without using
> > the mouse.  With the current way of defining region, you just go to
> > the other end, and you are immediately ready to invoke commands that
> > operate on the region.  How do you do that if point is not on one of
> > the edges of the region, except by dragging the mouse?
> 
> Commands limited to the selection can work with the selection without a
> need to even have the selection displayed on screen.

I don't see how this is relevant to the aspect of the Emacs region to
which I was referring.

> If you want to start making a selection where the cursor currently is,
> simply use the key binding to set a marker.  Otherwise, navigate to
> where you want to set the marker first.  You can use a trackball or not,
> it's unrelated.

How is this different from what we have now?

> To be able to go to the other end of the selection, you first have to
> make one.

That's why Emacs has a lot of commands that mark significant portions
of text: word, sentence, paragraph, sexp, etc.  Emacs also has a
matching set of cursor motion commands.  It makes all of that easy.

> There is no going to "the other end" of a region before a
> selection has been made, and once one has been made, there is no need to
> do that in order to do something with the selection

Emacs does that the other way around, but the result is no less
convenient and efficient.



reply via email to

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