Re: delete-selection-mode as default (WAS: Some developement questions)

Re: delete-selection-mode as default (WAS: Some developement questions)

[Bingo]

[-- Attachment #1: Type: text/plain, Size: 612 bytes --]

Hi,
  Can we consider changing defaults only for users who don't have any init file at all ?

  This change may not solve many problems, due to two other features of emacs : 

1. Emacs undo is frustrating for most new users. Correcting mistakes with delete-selection-mode i.e. restore a selection that was deleted due to a mistaken delete by typing/pasting , will need them to use undo. 

2. In their attempt to play with undo/redo, they might do C-y. Which pastes in Emacs : but it is the key for redo in many "modern" editors. This can cause more unintended deletions in delete-selection-mode.

Thanks

[-- Attachment #2: Type: text/html, Size: 662 bytes --]

Re: delete-selection-mode as default

[hw]

Bingo <right.ho@gmail.com> writes:

>   Can we consider changing defaults only for users who don't have any init file at all ?

Unexpectable behaviour of Emacs only because there is no ~/.emacs would
be confusing.

Which defaults is Emacs supposed to assume for settings that have not
been made in ~/.emacs because the user didn't need to change them before
the developers did?

>   This change may not solve many problems, due to two other features of emacs : 

These are problems of other editors.

> 1. Emacs undo is frustrating for most new users. Correcting mistakes
> with delete-selection-mode i.e. restore a selection that was deleted
> due to a mistaken delete by typing/pasting , will need them to use
> undo.

Every editor that doesn't understand Emacs` key bindings and doesn't
have its functions is frustrating (to use an euphemism).

Emacs` undo sucks when you need it more than once because you have to
press two keys for it.  Using a prefix doesn't work to make this easier
because I have no way of knowing how many times I have to use undo
before I get back to where I want to.  It is a really bad choice.

C-z can not easily be used for undo.  Other editors should never have
used it for that anyway.  I don't see why they would because it suspends
the process.

> 2. In their attempt to play with undo/redo, they might do C-y. Which
> pastes in Emacs : but it is the key for redo in many "modern"
> editors. This can cause more unintended deletions in
> delete-selection-mode.

This is another example of how delete-selection-mode supports making
mistakes.  Without it, C-y seems fine.  Shift+Insert works only in X
frames.

Now imagine you change the key binding for undo and for yank when there
is no ~/.emacs to make things easier for beginners.  The beginner uses
customize to change colours and to set a font and saves this settings.

Suddenly undo and yank --- and perhaps lots of other things --- "don't
work" anymore because the key bindings have changed.  Does that make
things easier for beginners --- or more difficult?

Re: delete-selection-mode as default

[Eli Zaretskii]

> From: hw <hw@adminart.net>
> Date: Sat, 08 Sep 2018 17:03:16 +0200
> Cc: emacs-devel@gnu.org
> 
> Emacs` undo sucks when you need it more than once because you have to
> press two keys for it.

Is C-/ and C-_ one key or two?  If two, then so it C-z; thus, Emacs is
not worse than other editors in this regard.

Re: delete-selection-mode as default

[hw]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: hw <hw@adminart.net>
>> Date: Sat, 08 Sep 2018 17:03:16 +0200
>> Cc: emacs-devel@gnu.org
>> 
>> Emacs` undo sucks when you need it more than once because you have to
>> press two keys for it.
>
> Is C-/ and C-_ one key or two?  If two, then so it C-z; thus, Emacs is
> not worse than other editors in this regard.

On a German keyboard with default bindings, those are both 3 keys each,
which are rather awkward to press: Shift+Control+7 and Shift+Control+-.

By that counting, C-x u is three keys, too, sorry.  It is less awkward
than the others.

I'm inconsistent with the counting because in most cases, I don't make
much difference between pressing a key together with or without a
modifier.  But when it becomes awkward, it does make a difference, and
the awkward part of C-x u is not the C-x but the u.  With the others,
all of it is awkward and they are definitely 3 keys :)

I guess this is how we learn to count to 3 eventually ;)

Re: delete-selection-mode as default

[Phil Sainty]

On 09/09/18 11:27, hw wrote:
>> Is C-/ and C-_ one key or two?  If two, then so it C-z; thus, Emacs is
>> not worse than other editors in this regard.
> 
> On a German keyboard with default bindings, those are both 3 keys each,
> which are rather awkward to press: Shift+Control+7 and Shift+Control+-.

That's unfortunate.

It's notable that of the CUA-style bindings, one can rebind C-z to
`undo' in Emacs without the same degree of conflict that the other CUA
keys introduce; so you might consider:

(global-set-key (kbd "C-z") #'undo)

C-z is `suspend-frame' by default (which makes complete sense when
Emacs is running in a terminal, so changing this default isn't an
option IMO), but it's a convenient key to *intentionally* re-purpose
if you know how to `suspend-frame' without it (n.b. C-x C-z is also
provided by default).  Because it's such a fundamental behaviour,
AFAIK no other default keymaps touch this key sequence.

Or you could pick any other convenient `undo' binding, of course
(but even then you might still change C-z.  I use C-z as a prefix
key, with C-z C-z as `suspend-frame', which I find provides me with
a very useful additional prefix for custom bindings.)


-Phil

RE: delete-selection-mode as default

[Drew Adams]

> It's notable that of the CUA-style bindings, one can rebind C-z to
> `undo' in Emacs without the same degree of conflict that the other CUA
> keys introduce; so you might consider:
> 
> (global-set-key (kbd "C-z") #'undo)
> 
> C-z is `suspend-frame' by default (which makes complete sense when
> Emacs is running in a terminal, so changing this default isn't an
> option IMO), but it's a convenient key to *intentionally* re-purpose
> if you know how to `suspend-frame' without it (n.b. C-x C-z is also
> provided by default).  Because it's such a fundamental behaviour,
> AFAIK no other default keymaps touch this key sequence.
> 
> Or you could pick any other convenient `undo' binding, of course
> (but even then you might still change C-z.  I use C-z as a prefix
> key, with C-z C-z as `suspend-frame', which I find provides me with
> a very useful additional prefix for custom bindings.)

One of the reasons I'm not a fan of `cua-mode' for Emacs is that
it wastes good prefix keys (C-x, C-c ). (Yes, I know that `cua-mode'
can accommodate to some extent this by way of timing, but that's
not good UI, IMO.)

I think C-z is wasted on a single action not only in `cua-mode' but
also in vanilla Emacs. It makes sense to use it as either a prefix key
or at least as a key that can be used for actions that are repeatable
(by holding down the key).

That said, for my own use I haven't bothered to use C-z as a
prefix key or for a repeatable command. I use it to thumbify
and dethumbify a frame (like iconify deiconify). But for
Emacs I think it should be used as stated above, not wasted
on `suspend-frame'.

Re: delete-selection-mode as default

[hw]

Phil Sainty <psainty@orcon.net.nz> writes:

> On 09/09/18 11:27, hw wrote:
>>> Is C-/ and C-_ one key or two?  If two, then so it C-z; thus, Emacs is
>>> not worse than other editors in this regard.
>> 
>> On a German keyboard with default bindings, those are both 3 keys each,
>> which are rather awkward to press: Shift+Control+7 and Shift+Control+-.
>
> That's unfortunate.

Fortunately, MOTT a single undo or a few are sufficient.  A few are
still ok, quite a few sucks, one reason being that it's easy to hit the
wrong key and screw up the undoing when you have to press C-x u so many
times.

> It's notable that of the CUA-style bindings, one can rebind C-z to
> `undo' in Emacs without the same degree of conflict that the other CUA
> keys introduce; so you might consider:
>
> (global-set-key (kbd "C-z") #'undo)
>
> C-z is `suspend-frame' by default (which makes complete sense when
> Emacs is running in a terminal, so changing this default isn't an
> option IMO), but it's a convenient key to *intentionally* re-purpose
> if you know how to `suspend-frame' without it (n.b. C-x C-z is also
> provided by default).  Because it's such a fundamental behaviour,
> AFAIK no other default keymaps touch this key sequence.
>
> Or you could pick any other convenient `undo' binding, of course
> (but even then you might still change C-z.  I use C-z as a prefix
> key, with C-z C-z as `suspend-frame', which I find provides me with
> a very useful additional prefix for custom bindings.)

I could use C-v for undo.  Too much customizing has the disadvantage of
getting in trouble with not or differently customized Emacs`.

Maybe I should look into a way to have all customization files Emacs
needs on a web browser or the like so they can easily be accessed and
used everywhere without having to have multiple copies in all places
which then need to be kept in sync.  I'm probably not the first one to
have this idea ...

Using git for this comes to mind, but it is horribly difficult to set up
access to a git repo when users do not have ssh access to the machine.
Emacs would have to clone the repo during startup to put all its files
into place.

But then, it could be done using a wrapper script that updates the repo
and then starts Emacs.  I'll give that some thought.

Re: delete-selection-mode as default

[Bingo]

[-- Attachment #1: Type: text/plain, Size: 2432 bytes --]

Le 8 septembre 2018 20:33:16 GMT+05:30, hw <hw@adminart.net> a écrit :
>Bingo <right.ho@gmail.com> writes:
>
>>   Can we consider changing defaults only for users who don't have any
>init file at all ?
>
>Unexpectable behaviour of Emacs only because there is no ~/.emacs would
>be confusing.
>
>Which defaults is Emacs supposed to assume for settings that have not
>been made in ~/.emacs because the user didn't need to change them
>before
>the developers did?
>
>>   This change may not solve many problems, due to two other features
>of emacs : 
>
>These are problems of other editors.
>
>> 1. Emacs undo is frustrating for most new users. Correcting mistakes
>> with delete-selection-mode i.e. restore a selection that was deleted
>> due to a mistaken delete by typing/pasting , will need them to use
>> undo.
>
>Every editor that doesn't understand Emacs` key bindings and doesn't
>have its functions is frustrating (to use an euphemism).
>
>Emacs` undo sucks when you need it more than once because you have to
>press two keys for it.  Using a prefix doesn't work to make this easier
>because I have no way of knowing how many times I have to use undo
>before I get back to where I want to.  It is a really bad choice.
>
>C-z can not easily be used for undo.  Other editors should never have
>used it for that anyway.  I don't see why they would because it
>suspends
>the process.
>
>> 2. In their attempt to play with undo/redo, they might do C-y. Which
>> pastes in Emacs : but it is the key for redo in many "modern"
>> editors. This can cause more unintended deletions in
>> delete-selection-mode.
>
>This is another example of how delete-selection-mode supports making
>mistakes.  Without it, C-y seems fine.  Shift+Insert works only in X
>frames.
>
>Now imagine you change the key binding for undo and for yank when there
>is no ~/.emacs to make things easier for beginners.  The beginner uses
>customize to change colours and to set a font and saves this settings.
>
>Suddenly undo and yank --- and perhaps lots of other things --- "don't
>work" anymore because the key bindings have changed.  Does that make
>things easier for beginners --- or more difficult?

I have clarified here : https://lists.gnu.org/archive/html/emacs-devel/2018-09/msg00330.html. Absence of init file is to be noticed only once. 

At other places in your email, is it sarcasm ?

Thanks

[-- Attachment #2: Type: text/html, Size: 3350 bytes --]

Re: delete-selection-mode as default

[hw]

Bingo <right.ho@gmail.com> writes:

> Le 8 septembre 2018 20:33:16 GMT+05:30, hw <hw@adminart.net> a écrit :
>>Bingo <right.ho@gmail.com> writes:
> [...]
> I have clarified here :
> https://lists.gnu.org/archive/html/emacs-devel/2018-09/msg00330.html. Absence
> of init file is to be noticed only once.

I think it might be better to let the users pick from selections of
skins and of groups of settings when there is no ~/.emacs: It leaves the
decisions to the users rather than secretly foisting settings and their
non-defaults upon them, which is something they might not be willing to
wolf down as easily as good defaults.

Skins might make Emacs appear more handsomely or prettier, and otherwise
more appealing, too.

> At other places in your email, is it sarcasm ?

How could I possibly answer that?

When I say "It depends on how seriously you take it.", I would be very
inappropriately sarcastic.  I could say "no", and you would think I'm
sarcastic.  If I say "It's only the way I write that can make it seem
so.", you don't know what to think.  Just asking which places you're
referring to could also make you think I'm sarcastic.

Re: delete-selection-mode as default (WAS: Some developement questions)

[Noam Postavsky]

>> > > > we should turn on `delete-selection-mode' by default.
>> > >
>> > > I don't think we can, because it gets in the way when editing code.
>> >
>> > How so? It doesn't get in my way. Quite the contrary - I appreciate
>> > it for editing code. Please give a recipe
>>
>> Type "C-x C-x", then some letter: puff! the whole region is gone.
>> This could be okay in text modes, but in code buffers users generally
>> don't replace regions with single letters.

I don't understand why a user who is okay with replacing the region
with a single letter in text mode, would all of sudden dislike the
idea in a code buffer.
Or, conversely, why a user who dislikes replacing the region with a
single letter in code buffers, would suddenly be happly about it in a
text buffer.

> It's equivalent to your doing this without `delete-selection-mode':
> C-x C-x M-w, then some letter

I guess you meant C-w there.

> I see zero difference between editing code and editing plain prose,
> in this regard. In both cases the selection can be replaced by typing,

As mentioned above, I agree with this.

> and that's a plus, not a minus.

Maybe. My feeling from using non-Emacs editors (gasp!), is that the
main use of this sort of thing is rather for replacing the selection
by pasting, not so about much typing. Or, for when some feature
inserts some default text, it highlights that text, indicating to the
user that they may replace it by typing (i.e., it's rare that a
user-created selection is deleted by typing).

Re: delete-selection-mode as default (WAS: Some developement questions)

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@gmail.com>
> Date: Thu, 6 Sep 2018 20:32:54 -0400
> Cc: Eli Zaretskii <eliz@gnu.org>, hw <hw@adminart.net>, spacibba@aol.com, 
> 	Emacs developers <emacs-devel@gnu.org>, Phillip Lord <phillip.lord@russet.org.uk>
> 
> >> Type "C-x C-x", then some letter: puff! the whole region is gone.
> >> This could be okay in text modes, but in code buffers users generally
> >> don't replace regions with single letters.
> 
> I don't understand why a user who is okay with replacing the region
> with a single letter in text mode, would all of sudden dislike the
> idea in a code buffer.

Because in text editing, it is a frequent use case that you want to
replace a region of text with some other long text; and also I find
myself in the need of doing "C-x C-x" much less frequently when I'm
editing text.  By contrast, in coding, most changes are of a much
smaller size, and "C-x C-x" is a very frequent command, due to the
need to look at other portions of the code.

> Maybe. My feeling from using non-Emacs editors (gasp!), is that the
> main use of this sort of thing is rather for replacing the selection
> by pasting, not so about much typing. Or, for when some feature
> inserts some default text, it highlights that text, indicating to the
> user that they may replace it by typing (i.e., it's rare that a
> user-created selection is deleted by typing).

It is exactly these features that get in the way when I write code.
It means I must click the mouse or do some cursor motion or C-g after
yanking, otherwise typing something will nuke the text just yanked.

Feel free to start a user poll, though: if it turns out I'm the only
one who thinks delete-selection-mode is inappropriate in programming
modes, we can make it the default; I can easily turn it off in my
configuration.  Though I would urge people to actually try this in
programming modes before responding, and in any case the poll should
request to provide the major modes used with the responses.

Re: delete-selection-mode as default

[hw]

Eli Zaretskii <eliz@gnu.org> writes:

> [...]
> Feel free to start a user poll, though: if it turns out I'm the only
> one who thinks delete-selection-mode is inappropriate in programming
> modes, we can make it the default; I can easily turn it off in my
> configuration.  Though I would urge people to actually try this in
> programming modes before responding, and in any case the poll should
> request to provide the major modes used with the responses.

When a selection is active, why would anyone assume that typing an
arbitrary letter is supposed to replace the entire selection, or to
disable it?  Allowing that to happen is simply a design flaw, or an
oversight.  And if that was allowed, it would be a case-specific
decision whether the selection should be replaced or disabled, not a
general one decidable by a default.

I would vote for a "strict-mode", or "static-selection-mode", meaning
that when a selection is active, typing an arbitrary letter makes Emacs
beep and otherwise do nothing.  It is always an accident when I type an
arbitrary letter while a selection is active, and it only makes the
accident worse when the selection is replaced, or disabled and the
letter is entered into the buffer.

Either I want to do something with a selection or not.  There is no
in-between.

Re: delete-selection-mode as default

[Clément Pit-Claudel]

On 2018-09-07 05:18, hw wrote:
> When a selection is active, why would anyone assume that typing an
> arbitrary letter is supposed to replace the entire selection, or to
> disable it?

Out of experience, mostly.  When almost every other program you use besides Emacs behaves that way, it's easy to assume that Emacs will behave the same way.

> Allowing that to happen is simply a design flaw, or an
> oversight.

I prefer to think of it as a very convenient feature.  For example, as I typed this email, I first wrote "as I composed" instead of "as I typed", pressed Control+Shift+Left Arrow, and pressed "typed".  Similarly, I had first written "I call it" instead of "I prefer to think of it", and the way I changed one into the other was to select "call it" and type "prefer to think of it as".

This select, then type to replace behavior is the norm in most programs I use outside Emacs, and it doesn't sound like a design flaw to me. Of course, Emacs' default behavior can be very convenient too, and it's good that it can do both.

Re: delete-selection-mode as default

[Robert Pluim]

Clément Pit-Claudel <cpitclaudel@gmail.com> writes:

> On 2018-09-07 05:18, hw wrote:
>> When a selection is active, why would anyone assume that typing an
>> arbitrary letter is supposed to replace the entire selection, or to
>> disable it?
>
> Out of experience, mostly.  When almost every other program you use
> besides Emacs behaves that way, it's easy to assume that Emacs will
> behave the same way.
>
>> Allowing that to happen is simply a design flaw, or an
>> oversight.
>
> I prefer to think of it as a very convenient feature.  For example, as
> I typed this email, I first wrote "as I composed" instead of "as I
> typed", pressed Control+Shift+Left Arrow, and pressed "typed".
> Similarly, I had first written "I call it" instead of "I prefer to
> think of it", and the way I changed one into the other was to select
> "call it" and type "prefer to think of it as".

Neither of those require 'replace selected' behaviour, since you could
easily use M-DEL instead. It could be useful when you need to replace
a word far away from point, although personally Iʼll use isearch to
get there, not the mouse.

> This select, then type to replace behavior is the norm in most
> programs I use outside Emacs, and it doesn't sound like a design flaw
> to me. Of course, Emacs' default behavior can be very convenient too,
> and it's good that it can do both.

Agreed.

Robert

Re: delete-selection-mode as default

[Dmitry Gutov]

On 9/7/18 4:28 PM, Robert Pluim wrote:

> Neither of those require 'replace selected' behaviour, since you could
> easily use M-DEL instead.

That implies one always replaces one word at a time. Which is not the 
case for me.

Personally, one of the reasons delete-selection-mode is handy is that 
while we have a handy key binding for 'kill-region', we don't have one 
for 'delete-region'.

Re: delete-selection-mode as default

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Date: Fri, 07 Sep 2018 15:28:31 +0200
> Cc: emacs-devel@gnu.org
> 
> > I prefer to think of it as a very convenient feature.  For example, as
> > I typed this email, I first wrote "as I composed" instead of "as I
> > typed", pressed Control+Shift+Left Arrow, and pressed "typed".
> > Similarly, I had first written "I call it" instead of "I prefer to
> > think of it", and the way I changed one into the other was to select
> > "call it" and type "prefer to think of it as".
> 
> Neither of those require 'replace selected' behaviour, since you could
> easily use M-DEL instead.

In Emacs, yes.  Let's not assume everybody here uses only Emacs for
each and every editing job.

So I'm with Clément on this one.

Re: delete-selection-mode as default

[Robert Pluim]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Robert Pluim <rpluim@gmail.com>
>> Date: Fri, 07 Sep 2018 15:28:31 +0200
>> Cc: emacs-devel@gnu.org
>> 
>> > I prefer to think of it as a very convenient feature.  For example, as
>> > I typed this email, I first wrote "as I composed" instead of "as I
>> > typed", pressed Control+Shift+Left Arrow, and pressed "typed".
>> > Similarly, I had first written "I call it" instead of "I prefer to
>> > think of it", and the way I changed one into the other was to select
>> > "call it" and type "prefer to think of it as".
>> 
>> Neither of those require 'replace selected' behaviour, since you could
>> easily use M-DEL instead.
>
> In Emacs, yes.  Let's not assume everybody here uses only Emacs for
> each and every editing job.

I try to, and then get very annoyed when other programs do things
differently (Iʼm looking at you here, Firefox URL bar).

> So I'm with Clément on this one.

I wasn't picking a side, nor do I think we should pick one for anyone
else.

Robert

RE: delete-selection-mode as default

[Drew Adams]

> I wasn't picking a side, nor do I think we should pick one for anyone
> else.

It's about the choice of a _default_ behavior. Currently one particular
choice was made. It's possible to choose a different one instead. In
any case the choice of the default behavior picks the behavior for
everyone - but only the default behavior.

Re: delete-selection-mode as default

[Robert Pluim]

Drew Adams <drew.adams@oracle.com> writes:

>> I wasn't picking a side, nor do I think we should pick one for anyone
>> else.
>
> It's about the choice of a _default_ behavior. Currently one particular
> choice was made. It's possible to choose a different one instead. In
> any case the choice of the default behavior picks the behavior for
> everyone - but only the default behavior.

Right. I meant that I donʼt think we should change the default
behaviour, but I won't scream if we do since I can always put it back.

Re: delete-selection-mode as default

[Jostein Kjønigsen]

[-- Attachment #1: Type: text/plain, Size: 1884 bytes --]

I realize Eli is a Emacs-vetaran and his opinion holds a lot of weight
here. That said....  > When a selection is active, why would anyone
assume that typing an > arbitrary letter is supposed to replace the
entire selection, or to > disable it?  Because that's what users expect
after this having been the default interaction model for all
applications for more than 3 decades.  I realize Emacs is older than
that, but trying to pretend that the outside world haven't established a
set of conventions people have come to expect is pretty much being the
ostrich sticking your head in the sand.  Adhering to the conventions the
user expect is user-friendly. We should do that by default when it
doesn't introduce needless complexity (like arguably enabling cua-mode
would).  That still leaves the option for power users, like yourself, to
customize the behaviour in non-conventional ways which you find
powerful.  I mean... I -love- paredit. It's amazing. But it clearly
should not be the *default* for editing LISP files, unless we want to
throw new-comers away before they've managed to say hello.

All in all, I vote for this change.
--
Regards
Jostein Kjønigsen

jostein@kjonigsen.net 🍵 jostein@gmail.com
https://jostein.kjonigsen.net


On Fri, Sep 7, 2018, at 7:08 PM, Robert Pluim wrote:
> Drew Adams <drew.adams@oracle.com> writes:
> 
>>> I wasn't picking a side, nor do I think we should pick one for
>>> anyone>>> else.
>> 
>> It's about the choice of a __default__ behavior. Currently one
>> particular>> choice was made. It's possible to choose a different one instead. In>> any case the choice of the default behavior picks the behavior for
>> everyone - but only the default behavior.
> 
> Right. I meant that I donʼt think we should change the default
> behaviour, but I won't scream if we do since I can always put it back.> 


[-- Attachment #2: Type: text/html, Size: 2952 bytes --]

Re: delete-selection-mode as default

[Stefan Monnier]

FWIW, while I personally don't use delete-selection-mode, I wouldn't
object to enabling it by default (I'd probably disable it in my .emacs,
but I'd first try to keep it enabled to see if I can change my habits).

But before that I'd appreciate if we could improve its implementation so
it doesn't rely on pre-command-hook.


        Stefan


Eli Zaretskii <eliz@gnu.org> writes:

>> From: Robert Pluim <rpluim@gmail.com>
>> Date: Fri, 07 Sep 2018 15:28:31 +0200
>> Cc: emacs-devel@gnu.org
>> 
>> > I prefer to think of it as a very convenient feature.  For example, as
>> > I typed this email, I first wrote "as I composed" instead of "as I
>> > typed", pressed Control+Shift+Left Arrow, and pressed "typed".
>> > Similarly, I had first written "I call it" instead of "I prefer to
>> > think of it", and the way I changed one into the other was to select
>> > "call it" and type "prefer to think of it as".
>> 
>> Neither of those require 'replace selected' behaviour, since you could
>> easily use M-DEL instead.
>
> In Emacs, yes.  Let's not assume everybody here uses only Emacs for
> each and every editing job.
>
> So I'm with Clément on this one.

Re: delete-selection-mode as default

[Juri Linkov]

> FWIW, while I personally don't use delete-selection-mode, I wouldn't
> object to enabling it by default (I'd probably disable it in my .emacs,
> but I'd first try to keep it enabled to see if I can change my habits).
>
> But before that I'd appreciate if we could improve its implementation so
> it doesn't rely on pre-command-hook.

Incidentally, yesterday I discovered a case when Wdired breaks
delete-selection-mode.  Selecting a file name in Wdired and starting
to type its new name to completely replace an old name with a new one
signals the error "No file on this line", then removes
delete-selection-pre-hook from pre-command-hook while leaving
delete-selection-mode still active, so delete-selection-mode becomes
completely broken - it doesn't replace the selection anymore.

I had to disable and then enable delete-selection-mode again
to get delete-selection-pre-hook back to pre-command-hook.

The error that removes delete-selection-pre-hook from pre-command-hook
logged in *Messages* is:

  Error in pre-command-hook (delete-selection-pre-hook): (error "No file on this line")

so relying on pre-command-hook is indeed the d-s-m's weak point.

Re: delete-selection-mode as default

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Sun, 09 Sep 2018 02:11:18 +0300
> Cc: emacs-devel@gnu.org
> 
> Incidentally, yesterday I discovered a case when Wdired breaks
> delete-selection-mode.  Selecting a file name in Wdired and starting
> to type its new name to completely replace an old name with a new one
> signals the error "No file on this line", then removes
> delete-selection-pre-hook from pre-command-hook while leaving
> delete-selection-mode still active, so delete-selection-mode becomes
> completely broken - it doesn't replace the selection anymore.

In what version of Emacs did you see that?

We recently fixed bug#32173, and the above sounds like something
similar.

Re: delete-selection-mode as default

[Juri Linkov]

>> Incidentally, yesterday I discovered a case when Wdired breaks
>> delete-selection-mode.  Selecting a file name in Wdired and starting
>> to type its new name to completely replace an old name with a new one
>> signals the error "No file on this line", then removes
>> delete-selection-pre-hook from pre-command-hook while leaving
>> delete-selection-mode still active, so delete-selection-mode becomes
>> completely broken - it doesn't replace the selection anymore.
>
> In what version of Emacs did you see that?
>
> We recently fixed bug#32173, and the above sounds like something
> similar.

Thanks for the reference, I can confirm it's caused by changes in
bug#32173 a month ago.  I reported a new bug#32673, but maybe it can be
merged with the already archived bug#32173.

This bug is a clear indication that delete-selection-mode needs to be moved
to simple.el where it will fit near shift-select-mode and transient-mark-mode.

RE: delete-selection-mode as default

[Drew Adams]

> > FWIW, while I personally don't use delete-selection-mode, I wouldn't
> > object to enabling it by default (I'd probably disable it in my .emacs,
> > but I'd first try to keep it enabled to see if I can change my habits).
> >
> > But before that I'd appreciate if we could improve its implementation so
> > it doesn't rely on pre-command-hook.
> 
> Incidentally, yesterday I discovered a case when Wdired breaks
> delete-selection-mode.  Selecting a file name in Wdired and starting
> to type its new name to completely replace an old name with a new one
> signals the error "No file on this line", then removes
> delete-selection-pre-hook from pre-command-hook while leaving
> delete-selection-mode still active, so delete-selection-mode becomes
> completely broken - it doesn't replace the selection anymore.
> 
> I had to disable and then enable delete-selection-mode again
> to get delete-selection-pre-hook back to pre-command-hook.
> 
> The error that removes delete-selection-pre-hook from pre-command-hook
> logged in *Messages* is:
> 
>   Error in pre-command-hook (delete-selection-pre-hook): (error "No file on this
> line")

I don't see that at all. What recipe did you use, in what Emacs release?

1. emacs -Q
2. Turn on d-s-m
3. Dired in some buffer
4. C-x C-q ; enable Wdired
5. Select a complete file name
6. Type to replace that name with another name
7. C-x C-q ; disable Wdired

At no point did Emacs raise an error.

In GNU Emacs 26.1 (build 1, x86_64-w64-mingw32)
 of 2018-05-30 built on CIRROCUMULUS
Repository revision: 07f8f9bc5a51f5aa94eb099f3e15fbe0c20ea1ea
Windowing system distributor 'Microsoft Corp.', version 10.0.16299

Re: delete-selection-mode as default

[Juri Linkov]

> But before that I'd appreciate if we could improve its implementation so
> it doesn't rely on pre-command-hook.

Reimplementing delete-selection-mode to be more like shift-select-mode
will also require to get rid of putting 'delete-selection props on
command symbols, and like shift-translated commands have a `^' character
in the `interactive' spec, delete-selection-mode might require a separate
character.  Hopefully, these types of commands are mutual exclusive,
so their disjoint sets won't cause conflicting interactive specs.

RE: delete-selection-mode as default

[Drew Adams]

> Reimplementing delete-selection-mode to be more like shift-select-mode
> will also require to get rid of putting 'delete-selection props on
> command symbols, and like shift-translated commands have a `^' character
> in the `interactive' spec, delete-selection-mode might require a separate
> character.  Hopefully, these types of commands are mutual exclusive,
> so their disjoint sets won't cause conflicting interactive specs.

Shift selection and `interactive'  `^' have nothing
whatsoever to do with `delete-selection-mode'.
D-s-m does not care how the text was selected.
And it works fine together with Shift selection.

It's not clear what you mean by making d-s-m
"more like shift-select-mode". But in any case I
disagree with such an incompatible change for d-s-m.

If you want something different from d-s-m (e.g.
"more like shift-select-mode) then please come up
with a new mode for that.

Please don't change the longstanding, simple, and
elegant d-s-m design, which includes the ability to
define the d-s-m behavior for a particular command
by putting a property on the command symbol.

This thread should really be about whether d-s-m
should be turned on by default. If you want something
different from d-s-m then, by all means, please
implement it - but using a new mode name.

Re: delete-selection-mode as default

[Juri Linkov]

> This thread should really be about whether d-s-m
> should be turned on by default. If you want something
> different from d-s-m then, by all means, please
> implement it - but using a new mode name.

It can not be turned on by default without reimplementation because of
bug#32673 so in fact you are voting against turning it on by default.

RE: delete-selection-mode as default

[Drew Adams]

> > This thread should really be about whether d-s-m
> > should be turned on by default. If you want something
> > different from d-s-m then, by all means, please
> > implement it - but using a new mode name.
> 
> It can not be turned on by default without reimplementation because of
> bug#32673 so in fact you are voting against turning it on by default.

Wasn't that bug introduced by particular changes trying to fix
bug #32173?  #32173 says that those changes "break d-s-m",
by inappropriately turning d-s-m off. Just don't do that. It's not
a problem with d-s-m itself, AFAICT.

Regardless. If you think d-s-m can't be turned on by default
then don't turn it on by default. But please don't mess with it.

Worse than not turning it on by default (who really cares that
much?) is ruining it, giving it an incompatible design. It doesn't
need a makeover. Please just leave it alone. 

We can wait another 30 years for someone to reconsider
turning it on by default (I won't be here, but I think it will
happen). I didn't really expect it to happen now. Maybe in
another decade or two...

Re: delete-selection-mode as default

[Juri Linkov]

> Wasn't that bug introduced by particular changes trying to fix
> bug #32173?  #32173 says that those changes "break d-s-m",
> by inappropriately turning d-s-m off. Just don't do that. It's not
> a problem with d-s-m itself, AFAICT.

This bug was caused by the fundamental flaw in its current implementation.

> Regardless. If you think d-s-m can't be turned on by default
> then don't turn it on by default. But please don't mess with it.
>
> Worse than not turning it on by default (who really cares that
> much?) is ruining it, giving it an incompatible design. It doesn't
> need a makeover. Please just leave it alone. 

Its reimplementation could have a different name: not delete-selection-mode,
but e.g. delete-select-mode (like handle-shift-selection vs shift-select-mode).

RE: delete-selection-mode as default

[Drew Adams]

> This bug was caused by the fundamental flaw in its current implementation.

I don't see a fundamental flaw in d-s-m. I see a bug in Wdired.

> Its reimplementation could have a different name: not delete-selection-mode,
> but e.g. delete-select-mode (like handle-shift-selection vs shift-select-mode).

Create a new mode for what you want, please. It's not about
"reimplementing" `delete-selection-mode'.

Call your new mode whatever you want. But IMO
"delete-select-mode" is not a great name. Besides sowing
confusion (obviously) with `delete-selection-mode',
"delete-select" is meaningless/contradictory or at best unclear.

`shift-select-mode' is OK as a name because it uses the Shift key
to select. It doesn't require an existing selection.

`delete-selection-mode' also makes sense, because it deletes
a selection - selected text. The selection must exist - the text
must have been selected - before it can be deleted.

Re: delete-selection-mode as default

[Jostein Kjønigsen]

[-- Attachment #1: Type: text/plain, Size: 728 bytes --]

On Tue, Sep 18, 2018, at 12:37 AM, Juri Linkov wrote:
>> This thread should really be about whether d-s-m
>> should be turned on by default. If you want something
>> different from d-s-m then, by all means, please
>> implement it - but using a new mode name.
> 
> It can not be turned on by default without reimplementation because of> bug#32673 so in fact you are voting against turning it on by default.> 

As far as I can see, a patch for that bug was pushed to master almost a
week ago, so I fail to see how that is a relevant argument now.
See commit: 755fa346eba212b4650c8541023bb78e1658d77b.

--
Regards
Jostein Kjønigsen

jostein@kjonigsen.net 🍵 jostein@gmail.com
https://jostein.kjonigsen.net



[-- Attachment #2: Type: text/html, Size: 1634 bytes --]

Re: delete-selection-mode as default

[Juri Linkov]

>>> This thread should really be about whether d-s-m
>>> should be turned on by default. If you want something
>>> different from d-s-m then, by all means, please
>>> implement it - but using a new mode name.
>>
>> It can not be turned on by default without reimplementation because of
>> bug#32673 so in fact you are voting against turning it on by default.>
>
> As far as I can see, a patch for that bug was pushed to master almost a
> week ago, so I fail to see how that is a relevant argument now.

The problem is that the current implementation of delete-selection-mode
is so fragile that any error signal in the hook will break it easily.

Re: delete-selection-mode as default

[hw]

Clément Pit-Claudel <cpitclaudel@gmail.com> writes:

> On 2018-09-07 05:18, hw wrote:
>> When a selection is active, why would anyone assume that typing an
>> arbitrary letter is supposed to replace the entire selection, or to
>> disable it?
>
> Out of experience, mostly.  When almost every other program you use
> besides Emacs behaves that way, it's easy to assume that Emacs will
> behave the same way.

It's not my experience because when I want a selection deleted, I delete
it.  If it gets deleted otherwise, that's a mistake or maybe even a bug
when no undo is available.

>> Allowing that to happen is simply a design flaw, or an
>> oversight.
>
> I prefer to think of it as a very convenient feature.  For example, as
> I typed this email, I first wrote "as I composed" instead of "as I
> typed", pressed Control+Shift+Left Arrow, and pressed "typed".
> Similarly, I had first written "I call it" instead of "I prefer to
> think of it", and the way I changed one into the other was to select
> "call it" and type "prefer to think of it as".
>
> This select, then type to replace behavior is the norm in most
> programs I use outside Emacs, and it doesn't sound like a design flaw
> to me.

I call it a design flaw because if whoever made it this way had given
any thought to it, it would at least be customizable --- and, as said,
because when I want a selection deleted or to be unselected, I delete it
or unselect it, and having a selection randomly disappear like by tying
letters means making a mistake worse.  Software supporting users in
making mistakes and making the mistakes even worse suffers from design
flaws unless doing so is the very purpose of the software.

I suspect that one important reason for the dangerous and careless
dealing with selections you find in many other programs is that the
developers couldn't be bothered to find a better way.

The behaviour is inconsistant, too: insert a frame into a text document
with Libreoffice, keep the frame selected and type something.  Surprise!
This obviously hasn't been thought through, and the behaviour LO shows
here is a design flaw.

> Of course, Emacs' default behavior can be very convenient too,
> and it's good that it can do both.

right

Maybe the default should be changed, as well as Alt-left and Alt-right
should go backward and forward in info history.  But then Emacs would
default to supporting users in making mistakes and make them worse.

RE: delete-selection-mode as default

[Drew Adams]

> I call it a design flaw because if whoever made it this way had given
> any thought to it, it would at least be customizable

Actually, beyond being customizable by configuring it to be on or
off by default, it is customizable (but not just by using Customize),
in a fine-grained way.

You can easily configure the behavior to use for any given command,
by putting a particular `delete-selection' property value on its symbol.

These are the possible `delete-selection' property values:

* `yank' - For commands that do a yank.  Ensures that the region
about to be deleted is not yanked.

* `supersede' - Delete the active region and ignore the current
command: the command just deletes the region.

* `kill' - `kill-region' is used on the selection, rather than
`delete-region'.  (Text selected with the mouse is
typically yankable anyway.)

* anything else non-nil - Deletes the active region prior to
executing the command, which inserts replacement
text.  This is the usual case.

Commands that insert text but do not have property
`delete-selection' (or commands for which it's value is nil)
do not delete the selection.

For example: 

;; Don't let `insert-char' delete the selection.
(put 'insert-char 'delete-selection nil)

More typically is the case where a library defines a new
editing command that it wants to make susceptible to
`delete-selection-mode'. For example:

;; Let delete-selection mode delete the region. 
(put 'icicle-delete-char 'delete-selection 'supersede)

Simple, elegant command-specific behavior. Trivial to
configure - for both users and libraries.

Re: delete-selection-mode as default

[Clément Pit-Claudel]

On 2018-09-07 10:39, hw wrote:
>> On 2018-09-07 05:18, hw wrote:
>>> When a selection is active, why would anyone assume that typing
>>> an arbitrary letter is supposed to replace the entire selection,
>>> or to disable it?

>> Out of experience, mostly.  When almost every other program you
>> use besides Emacs behaves that way, it's easy to assume that Emacs
>> will behave the same way.

> It's not my experience because when I want a selection deleted, I
> delete it.  If it gets deleted otherwise, that's a mistake or maybe
> even a bug when no undo is available.

You seem to be conflating experience and desirable behavior.

> I call it a design flaw because if whoever made it this way had
> given any thought to it, it would at least be customizable

Fortunately, some of those who "made it that way" did think about it :)  For example, Microsoft Word has an option called "Typing Replaces Selected Text."  Unfortunately, I couldn't find a similar setting in OpenOffice, nor in LibreOffice.
Gtk entries and textviews do not seem to provide a similar setting, either, but I wouldn't assume that they didn't give any thought to it.

> Software supporting users in making mistakes and making the mistakes
> even worse suffers from design flaws unless doing so is the very
> purpose of the software.

I'm having trouble following the reasoning.  

> I suspect that one important reason for the dangerous and careless
> dealing with selections you find in many other programs is that the
> developers couldn't be bothered to find a better way.

I understand that feeling, but I don't see much to support it.  From the same observations, you could just as well conclude that no one cared enough about the behavior offered by Emacs to send patches to OpenOffice, Gtk, or many of the other libre IDEs and text editors.

Re: delete-selection-mode as default

[hw]

Clément Pit-Claudel <cpitclaudel@gmail.com> writes:

> On 2018-09-07 10:39, hw wrote:
>>> On 2018-09-07 05:18, hw wrote:
>>>> When a selection is active, why would anyone assume that typing
>>>> an arbitrary letter is supposed to replace the entire selection,
>>>> or to disable it?
>
>>> Out of experience, mostly.  When almost every other program you
>>> use besides Emacs behaves that way, it's easy to assume that Emacs
>>> will behave the same way.
>
>> It's not my experience because when I want a selection deleted, I
>> delete it.  If it gets deleted otherwise, that's a mistake or maybe
>> even a bug when no undo is available.
>
> You seem to be conflating experience and desirable behavior.

You could say that --- as long as I don't press the wrong key, I'm
getting desirable behaviour.

>> I call it a design flaw because if whoever made it this way had
>> given any thought to it, it would at least be customizable
>
> Fortunately, some of those who "made it that way" did think about it
> :)  For example, Microsoft Word has an option called "Typing Replaces
> Selected Text."

That's a good thing.

> Unfortunately, I couldn't find a similar setting in OpenOffice, nor in
> LibreOffice. Gtk entries and textviews do not seem to provide a
> similar setting, either, but I wouldn't assume that they didn't give
> any thought to it.

Why not?

>> Software supporting users in making mistakes and making the mistakes
>> even worse suffers from design flaws unless doing so is the very
>> purpose of the software.
>
> I'm having trouble following the reasoning.  

Hm, let my try to explain:

The reasoning assumes that one important benefit of software is the
possibility to prevent mistakes, for example by validating the input
made by a user and by questioning or rejecting it when it is suspicious.

You can design software such that it provides this benefit and such that
it does not.  You can also design software such that it makes it more
likely that mistakes happen and such that it makes the effects of
mistakes worse.  In case it was not your intention to design your
software so that it makes it more likely that mistakes will happen, or
that it makes mistakes worse, but your software does that, your software
has a design flaw.

As for selections, this means that you can make your software so that
not every random keystroke makes them disappear, or you can make your
software so that the selection basically disappears with every random
keystroke.

Since random, accidental keystrokes sometimes happen, your software ---
assuming its purpose is not to make mistakes worse --- has a greater
benefit to the user and no design flaw when it protects the user from
such mistakes by not letting the selection disappear.

It can't very well protect the user from random, accidental keystrokes,
but it can make the mistake worse by making the selection disappear when
they occur.  If it does that, it has a design flaw.

Of course, there can be a problem when the user does not want to be
protected, or when it becomes troublesome to use the software because it
is overprotective.

In case of Emacs, a user can make a setting that makes the effect of
mistakes worse.  Some users are asking to make this the default while
others are against it.

>> I suspect that one important reason for the dangerous and careless
>> dealing with selections you find in many other programs is that the
>> developers couldn't be bothered to find a better way.
>
> I understand that feeling, but I don't see much to support it.  From
> the same observations, you could just as well conclude that no one
> cared enough about the behavior offered by Emacs to send patches to
> OpenOffice, Gtk, or many of the other libre IDEs and text editors.

I don't understand how multiple possible reasons for the impossibility
of bothering the developers would not all the more support the suspicion
that they couldn't be bothered.

Re: delete-selection-mode as default

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I find it a screw that Backspace deletes a highlighted region.  It is
never what I want -- I always want to delete one character backwards.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: delete-selection-mode as default

[Elias Mårtenson]

[-- Attachment #1: Type: text/plain, Size: 614 bytes --]

On Sat, 8 Sep 2018, 13:17 Richard Stallman, <rms@gnu.org> wrote:

>
> I find it a screw that Backspace deletes a highlighted region.  It is
> never what I want -- I always want to delete one character backwards.
>

I believe that the whole idea of active regions was a mistake, and even
though it can be disabled, some Emacs code these days assume it's on to the
extent that 1) it misbehaves when it's off, and 2) it gets turned on
automatically when it's loaded (I'm looking at you, company-mode).

Without active regions, there would never be an expectation that backspace
deletes anything but one character.

>

[-- Attachment #2: Type: text/html, Size: 1139 bytes --]

Re: delete-selection-mode as default

[Eli Zaretskii]

> From: Elias Mårtenson <lokedhs@gmail.com>
> Date: Sat, 8 Sep 2018 19:32:24 +0800
> Cc: cpitclaudel@gmail.com, emacs-devel <emacs-devel@gnu.org>
> 
> some Emacs code these days assume [active regions are enabled] to
> the extent that 1) it misbehaves when it's off, and 2) it gets
> turned on automatically when it's loaded (I'm looking at you,
> company-mode).

Please be sure to report those cases as bugs.

Thanks.

Re: delete-selection-mode as default

[hw]

Elias Mårtenson <lokedhs@gmail.com> writes:

> Without active regions, there would never be an expectation that backspace
> deletes anything but one character.

How come it wasn't distinguished between the concept of a region being
active and the visual aid of marking a region?

What's with the inconsistency that functions like query-replace are
/limited/ to the region while others, like backward-delete-char, are
/extended/ to the region when it is active?

I think for the strict-selection-mode I'd prefer, it would help to
disable transient-mark-mode.  But how can I see what I have selected?

It would even be possible to leave the visual markers active while the
user is doing something else if transient-mark-mode didn't insist on the
region being active when it's visually highlighted.  It would only need
a key binding to stop marking a region.  I'd appreciate it if I didn't
need to always do something with a region immediately and could leave it
highlighted, or leave several regions highlighted at the same time.

It seems transient-mark-mode started as a good idea and has evolved into
a very special weirdness which now attracts other weirdnesses, like
dangerous selection modes.

Re: delete-selection-mode as default

[Charles A. Roelli]

> From: hw <hw@adminart.net>
> Cc: Richard Stallman <rms@gnu.org>, cpitclaudel@gmail.com,
> 	emacs-devel <emacs-devel@gnu.org>
> Date: Sat, 08 Sep 2018 17:52:07 +0200
> 
> Elias Mårtenson <lokedhs@gmail.com> writes:
> 
> > Without active regions, there would never be an expectation that backspace
> > deletes anything but one character.
> 
> How come it wasn't distinguished between the concept of a region being
> active and the visual aid of marking a region?

Separating these two concepts could be useful, but Emacs would then
need some other way of showing the user that a region is active, like
a mode line indicator.  We would then also need bindings for
activating and deactivating the region, and for turning the visual aid
on and off.

> [...]
> 
> I think for the strict-selection-mode I'd prefer, it would help to
> disable transient-mark-mode.  But how can I see what I have selected?

The most common answer to that is to use "C-u C-x C-x", which
temporarily activates the region (thus highlighting it) and exchanges
the point and the mark.  But there is no command to turn on the
highlighting of the region directly.

> It would even be possible to leave the visual markers active while the
> user is doing something else if transient-mark-mode didn't insist on the
> region being active when it's visually highlighted.  

I'd like this too.

> 						       It would only need
> a key binding to stop marking a region.  I'd appreciate it if I didn't
> need to always do something with a region immediately and could leave it
> highlighted, or leave several regions highlighted at the same time.

For a second region, use the secondary selection.  We don't yet have
keyboard bindings for its commands, unfortunately, though Drew's
package "second-sel" suggests C-M-y:

https://www.emacswiki.org/emacs/SecondarySelection#second-sel.el

RE: delete-selection-mode as default

[Drew Adams]

> For a second region, use the secondary selection.  We don't yet have
> keyboard bindings for its commands, unfortunately, though Drew's
> package "second-sel" suggests C-M-y:

For some reason I tend to use the secondary selection quite
a lot. I think that most users never use it. For what it does I
prefer it over using a string register, generally.

Re: delete-selection-mode as default

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > How come it wasn't distinguished between the concept of a region being
  > > active and the visual aid of marking a region?

  > Separating these two concepts could be useful, but Emacs would then
  > need some other way of showing the user that a region is active, like
  > a mode line indicator.

We could have another minor mode to control whether Backspace deletes
an active region.  That would solve the problem for me.  We would still
have the issue of what the default should be.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

RE: delete-selection-mode as default

[Drew Adams]

>   > > How come it wasn't distinguished between the concept of a region being
>   > > active and the visual aid of marking a region?
> 
>   > Separating these two concepts could be useful, but Emacs would then
>   > need some other way of showing the user that a region is active, like
>   > a mode line indicator.
> 
> We could have another minor mode to control whether Backspace deletes
> an active region.  That would solve the problem for me.  We would still
> have the issue of what the default should be.

1. The behavior you object to here does not come from `d-s-m'.
(I guess you realize that, since you see the behavior and you don't
turn on `d-s-m'.) It comes from option `delete-active-region':

----8<------
delete-active-region is a variable defined in `simple.el'.
Its value is t

Documentation:
Whether single-char deletion commands delete an active region.
This has an effect only if Transient Mark mode is enabled, and
affects `delete-forward-char' and `delete-backward-char', though
not `delete-char'.

If the value is the symbol `kill', the active region is killed
instead of deleted.

You can customize this variable.

This variable was introduced, or its default value was changed, in
version 24.1 of Emacs.
----8<------

So you don't need another mode, to get what you want; just
customize that option.


2. Wrt `d-s-m', you can easily configure `d-s-m' to do what you want
for any given command. For example, if you were seeing the
behavior that you dislike here because `d-s-m' was turned on (and
not because of `delete-active-region') then you could just tell
`d-s-m' not to do anything for the command that you have bound
to <backspace>.

All you need to do, to make `d-s-m' do nothing for a given
command, is to set the `delete-section' property on that
command's symbol to nil. E.g., if `d-s-m' was the culprit in the
behavior you object to here, and if <backspace> was bound to
`delete-backward-char', then you would just do this:

(put 'delete-backward-char 'delete-selection nil)

Re: delete-selection-mode as default

[hw]

Drew Adams <drew.adams@oracle.com> writes:

> [...]
> ----8<------
> delete-active-region is a variable defined in `simple.el'.
> Its value is t

Thank you!  This brings it closer to the "static-selection-mode" I
prefer :)

Re: delete-selection-mode as default

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

ELi and I, the Emacs maintainers, are both opposed to making
delete-selection-mode the default.  Please don't do that.

The stated aim of that change is to cater to newcomers at the expense
of experienced users.  That is a clumsy and unhelpful approach.  If we
think about it, maybe we can cater better to all users.

See my other message for one specific idea.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: delete-selection-mode as default

[hw]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > > How come it wasn't distinguished between the concept of a region being
>   > > active and the visual aid of marking a region?
>
>   > Separating these two concepts could be useful, but Emacs would then
>   > need some other way of showing the user that a region is active, like
>   > a mode line indicator.
>
> We could have another minor mode to control whether Backspace deletes
> an active region.  That would solve the problem for me.  We would still
> have the issue of what the default should be.

I think the whole concept of regions could use an overhaul.

The next mode after the one saving backspace from deleting regions might
make it so that delete deletes regions because it should work in
consistency with backspace when the backspace mode is not enabled.

Re: delete-selection-mode as default

[Dmitry Gutov]

On 08.09.2018 14:32, Elias Mårtenson wrote:

> I believe that the whole idea of active regions was a mistake, and even 
> though it can be disabled, some Emacs code these days assume it's on to 
> the extent that 1) it misbehaves when it's off, and 2) it gets turned on 
> automatically when it's loaded (I'm looking at you, company-mode).

What does company-mode have to do with it?

Re: delete-selection-mode as default

[Elias Mårtenson]

[-- Attachment #1: Type: text/plain, Size: 732 bytes --]

On Sun, 9 Sep 2018, 02:16 Dmitry Gutov, <dgutov@yandex.ru> wrote:

> On 08.09.2018 14:32, Elias Mårtenson wrote:
>
> > I believe that the whole idea of active regions was a mistake, and even
> > though it can be disabled, some Emacs code these days assume it's on to
> > the extent that 1) it misbehaves when it's off, and 2) it gets turned on
> > automatically when it's loaded (I'm looking at you, company-mode).
>
> What does company-mode have to do with it?
>

When I turn it on, I get active regions enabled. However, now that I'm
thinking about it, I also turn on Flycheck at the same time, so I might
have misplaced the accusation.

I will try it again once I'm back on my computer.

Regards,
Elias

>

[-- Attachment #2: Type: text/html, Size: 1353 bytes --]

Re: delete-selection-mode as default

[Clément Pit-Claudel]

On 2018-09-09 03:42, Elias Mårtenson wrote:
> When I turn it on, I get active regions enabled. However, now that
> I'm thinking about it, I also turn on Flycheck at the same time, so I
> might have misplaced the accusation.

I feel pretty safe on that one :) I just checked, and the sources in flycheck.el do not contain the word "selection".

Re: delete-selection-mode as default (WAS: Some developement questions)

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Sep 07, 2018 at 09:47:52AM +0300, Eli Zaretskii wrote:

[...]

> Feel free to start a user poll, though: if it turns out I'm the only
> one who thinks delete-selection-mode is inappropriate in programming
> modes [...]

This is from a seat far back in the peanut gallery, but no, Eli, you
aren't the only one :-)

I know this "delete selection on  typing" behaviour, and I dislike it
with passion.

Typical case of "two cultures", I guess.

Cheers
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAluSyw8ACgkQBcgs9XrR2kYM/QCdGIOa/kwS1QS3eXcsTOBa88B0
TaMAnRfUuD1fveUU2Ng7ZLEoFBxoaSk3
=hoZm
-----END PGP SIGNATURE-----

RE: delete-selection-mode as default (WAS: Some developement questions)

[Drew Adams]

> Typical case of "two cultures", I guess.

Really? What two cultures are those?

Different default values of `delete-selection-mode'?
Or are you trying to suggest some wider difference
that is indicated/reflected by that difference?

IMHO, this is only about that specific difference. I doubt
that you will find meaningful alignment/correlation between
views on that question and other views, including other views
about editing or Emacs.

I wouldn't advise generalizing this to include pro/con
mouse, menus, key bindings, GUI, visual lines, fonts, OS,...

Re: delete-selection-mode as default (WAS: Some developement questions)

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1027 bytes --]

On Fri, Sep 07, 2018 at 12:23:07PM -0700, Drew Adams wrote:
> > Typical case of "two cultures", I guess.
> 
> Really? What two cultures are those?
> 
> Different default values of `delete-selection-mode'?
> Or are you trying to suggest some wider difference
> that is indicated/reflected by that difference?

I think you are reading too much into what I wrote, but
I'm not sure.

> IMHO, this is only about that specific difference. I doubt
> that you will find meaningful alignment/correlation between
> views on that question and other views, including other views
> about editing or Emacs.

I guess there's some alignment. I always feel awkward when
editing in a browser, for example. It reminds me fatally
of Notepad, back then. And it's not just selection handling.

But hey, everyone swings differently.

> I wouldn't advise generalizing this to include pro/con
> mouse, menus, key bindings, GUI, visual lines, fonts, OS,...

I think it's more subtle, but somehow related, yes.

Cheers
-- t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: delete-selection-mode as default

[Juri Linkov]

>> IMHO, this is only about that specific difference. I doubt
>> that you will find meaningful alignment/correlation between
>> views on that question and other views, including other views
>> about editing or Emacs.
>
> I guess there's some alignment. I always feel awkward when
> editing in a browser, for example. It reminds me fatally
> of Notepad, back then. And it's not just selection handling.
>
> But hey, everyone swings differently.

To me, delete-selection-mode is an optimization, it saves keystrokes
allowing to type less - I don't need to type DEL to delete an old region
before replacing it with new text.  Also jumping to the previous mark
is easy with C-u C-SPC when there is no need to select the region
as C-x C-x does.  And I never make a mistake when I see that the region
is active to not replace it mistakenly.

Re: delete-selection-mode as default

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, Sep 09, 2018 at 02:19:31AM +0300, Juri Linkov wrote:
> >> IMHO, this is only about that specific difference. I doubt
> >> that you will find meaningful alignment/correlation between
> >> views on that question and other views, including other views
> >> about editing or Emacs.
> >
> > I guess there's some alignment. I always feel awkward when
> > editing in a browser, for example. It reminds me fatally
> > of Notepad, back then. And it's not just selection handling.
> >
> > But hey, everyone swings differently.
> 
> To me, delete-selection-mode is an optimization, it saves keystrokes
> allowing to type less [...]

What most people saying "_my_ way is better" tend to forget is context:
you've adapted your micro workflow to your tools and viceversa.

So if you say "it saves keystrokes", this is from the (very limited)
perspective of *your* context. People preferring "the other" toolset
will have planned the whole thing differently, they'll use selection
in subtly different ways, etc. etc.

All generalizations suck.

Cheers
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAluU04kACgkQBcgs9XrR2kblDACeKFWoDz3wAx0UTMgzdjEcgDTJ
j+gAoIBif240c76e4v0L+QLfyTpW8ADP
=/xWu
-----END PGP SIGNATURE-----

Re: delete-selection-mode as default (WAS: Some developement questions)

[Noam Postavsky]

On 7 September 2018 at 15:01,  <tomas@tuxteam.de> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Fri, Sep 07, 2018 at 09:47:52AM +0300, Eli Zaretskii wrote:
>
> [...]
>
>> Feel free to start a user poll, though: if it turns out I'm the only
>> one who thinks delete-selection-mode is inappropriate in programming
>> modes [...]
>
> This is from a seat far back in the peanut gallery, but no, Eli, you
> aren't the only one :-)
>
> I know this "delete selection on  typing" behaviour, and I dislike it
> with passion.

But do you think it's ok for text (non-programming) buffers?

Re: delete-selection-mode as default (WAS: Some developement questions)

[tomas]

[-- Attachment #1: Type: text/plain, Size: 546 bytes --]

On Fri, Sep 07, 2018 at 04:33:11PM -0400, Noam Postavsky wrote:
> On 7 September 2018 at 15:01,  <tomas@tuxteam.de> wrote:

[...]

> > I know this "delete selection on  typing" behaviour, and I dislike it
> > with passion.
> 
> But do you think it's ok for text (non-programming) buffers?

In my case (and I _know_ it's very personal, I wouldn't want to
impose my taste on anyone!) no: programming and text are more
or less equivalent (sometimes I try to mix both).

But then, I'm also a "point-to-focus" type =:-o

Cheers
-- t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: delete-selection-mode as default

[Robert Pluim]

[-- Attachment #1: Type: text/plain, Size: 623 bytes --]

tomas@tuxteam.de writes:

> On Fri, Sep 07, 2018 at 04:33:11PM -0400, Noam Postavsky wrote:
>> On 7 September 2018 at 15:01,  <tomas@tuxteam.de> wrote:
>
> [...]
>
>> > I know this "delete selection on  typing" behaviour, and I dislike it
>> > with passion.
>> 
>> But do you think it's ok for text (non-programming) buffers?
>
> In my case (and I _know_ it's very personal, I wouldn't want to
> impose my taste on anyone!) no: programming and text are more
> or less equivalent (sometimes I try to mix both).

Typing is typing, indeed.

> But then, I'm also a "point-to-focus" type =:-o

Heretic! ;-)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: delete-selection-mode as default

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Sep 10, 2018 at 10:01:10AM +0200, Robert Pluim wrote:
> tomas@tuxteam.de writes:

[...]

> > But then, I'm also a "point-to-focus" type =:-o
> 
> Heretic! ;-)

Yes, we are those for whom the XFlame screen saver was made...

;-)

- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAluWJtAACgkQBcgs9XrR2kYqqACcDPWBA10mqHtbm0VDAsG2pVln
c2oAn3cn8lR+j5JwJF/LUpoI/jiXxTkM
=ZZ46
-----END PGP SIGNATURE-----

Re: delete-selection-mode as default (WAS: Some developement questions)

[Alan Mackenzie]

Hello, Eli.

On Fri, Sep 07, 2018 at 09:47:52 +0300, Eli Zaretskii wrote:
> Feel free to start a user poll, though: if it turns out I'm the only
> one who thinks delete-selection-mode is inappropriate in programming
> modes, we can make it the default; I can easily turn it off in my
> configuration.  Though I would urge people to actually try this in
> programming modes before responding, and in any case the poll should
> request to provide the major modes used with the responses.

No, you're not the only disliker of d-s-mode.  I utterly detest it, to
the point that Emacs's lack of this feature was one of the things which
attracted me to Emacs in the first place.  At last, an editing program
with a rational, well thought out interface!  A thing I hated about these
other programs was that I could have spent a long time building up a
(highlighted) region in them, only to lose it irretrievably on carelessly
typing an arrow key without <shift>.  As a result of things like that, I
was never able to relax whilst using these programs - I had to remain
hyper-alert to avoid the above sort of lossage.

I appreciate that Emacs's d-s-mode doesn't suffer all these drawbacks,
but it does suffer some of them.

I believe delete-selection-mode is objectively bad; deleting/killing
potentially large areas of text should not occur as a side effect of
something whose main action is smalll (like inserting a single
character).  As well as being bad UI, it violates the "do one thing and
do it well" principle.

In the current polling exercise, I would urge those interpreting the
responses to take account not merely of the numbers of
supporters/detractors but the strength of feeling behind those responses.
I've seen several such that strongly dislike d-s-mode, but haven't seen
any saying "I utterly detest editors lacking delete-selection-mode".
That suggests to me that we should not enable this mode by default.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: delete-selection-mode as default

[Filipp Gunbin]

On 09/09/2018 13:45 +0000, Alan Mackenzie wrote:

> Hello, Eli.
>
> On Fri, Sep 07, 2018 at 09:47:52 +0300, Eli Zaretskii wrote:
>> Feel free to start a user poll, though: if it turns out I'm the only
>> one who thinks delete-selection-mode is inappropriate in programming
>> modes, we can make it the default; I can easily turn it off in my
>> configuration.  Though I would urge people to actually try this in
>> programming modes before responding, and in any case the poll should
>> request to provide the major modes used with the responses.
>
> No, you're not the only disliker of d-s-mode.  I utterly detest it, to
> the point that Emacs's lack of this feature was one of the things which
> attracted me to Emacs in the first place.  At last, an editing program
> with a rational, well thought out interface!  A thing I hated about these
> other programs was that I could have spent a long time building up a
> (highlighted) region in them, only to lose it irretrievably on carelessly
> typing an arrow key without <shift>.  As a result of things like that, I
> was never able to relax whilst using these programs - I had to remain
> hyper-alert to avoid the above sort of lossage.

Much the same for me.

I think that if we ever make d-s-m on by default, we should add a line
or two about it in tutorial.  And also about transient-mark-mode (and
maybe visual-line-mode).  It's especially new users (for whom the
tutorial is designed) that might be unaware of different ways of
handling selection.  They may not like "the old way", but at least
they'll know about it.

Filipp

Re: delete-selection-mode as default (WAS: Some developement questions)

[Joost Kremers]

On Fri, Sep 07 2018, Eli Zaretskii wrote:
> Feel free to start a user poll, though: if it turns out I'm the 
> only
> one who thinks delete-selection-mode is inappropriate in 
> programming
> modes, we can make it the default; I can easily turn it off in 
> my
> configuration.  Though I would urge people to actually try this 
> in
> programming modes before responding, and in any case the poll 
> should
> request to provide the major modes used with the responses.

My €0.02: I'd say this thread has already shown that a poll won't 
be of much help here. Whether you prefer `delete-selection-mode` 
on or off really depends on your workflow, and de fluminibus 
operis non est disputandum, to paraphrase a well-known adage.

So I'd suggest that any decision regarding the default value of 
`delete-selection-mode` should not be based on such 
considerations. Rather, two questions should be considered: a) 
"Would leaving it off scare away potential new users?" and b) 
"Would turning it on obscure an option that is potentially useful 
to at least a subset of new users?"

I suspect the answer to both questions is "yes". If you're trying 
out a new piece of software, any behaviour that differs from what 
you're used to (after all, what `delete-selection-mode` does is 
standard behaviour in most software out there and most new users 
will take it for granted) is off-putting and might lead you to 
give up, especially if it's not immediately clear why the 
behaviour is different.

On the other hand, if `delete-selection-mode` is on by default, 
most, if not all, new users will never even consider the 
possibility that Emacs has the option to disable it and that that 
might actually fit their workflow better.

All in all, despite having `delete-selection-mode` on myself, I 
think it should be kept off by default, but with a note in the 
tutorial somewhere that it can be turned on. Or perhaps it could 
be made such that the first time a new user types a character with 
an active region, a message pops up saying that Emacs doesn't 
normally overwrite an active region, with an explanation why and a 
note that it can be configured to do so if desired. It would be 
similar to how disabled commands work (though IIUC it couldn't be 
implemented easily as a disabled command, so adding such a 
mechanism might not be trivial).




-- 
Joost Kremers
Life has its moments

RE: delete-selection-mode as default (WAS: Some developement questions)

[Drew Adams]

I agree that a poll of this list is not a great guide (for this question
and many others).

> Two questions should be considered: a) "Would leaving it off scare
> away potential new users?" and b) "Would turning it on obscure an
> option that is potentially useful to at least a subset of new users?"

I must have missed what that potentially useful option is.

> On the other hand, if `delete-selection-mode` is on by default,
> most, if not all, new users will never even consider the
> possibility that Emacs has the option to disable it and that
> that might actually fit their workflow better.

This too hints at some advantage to having it off.

The only argument I saw here (unless I've forgotten already)
in favor of it being off (by default or not) is that when it is on
a user (new or old) can too easily accidentally delete text.

(Some added "irretrievably", but I haven't seen that claim
supported yet.)

That advantage would seem to be something that would
most benefit new users, no? But the claim has been that
new users are more used to the on, not the off, behavior.

So again, what's the advantage to it being off? (It's not a
rhetorical question.) Is there really some useful "option"
that its being off offers? Does that give you additional
choice or control?

Re: delete-selection-mode as default (WAS: Some developement questions)

[Bingo]

On Sun, 9 Sep 2018 15:24:30 -0700 (PDT)
Drew Adams <drew.adams@oracle.com> wrote:

> So again, what's the advantage to it being off? (It's not a
> rhetorical question.) Is there really some useful "option"
> that its being off offers? Does that give you additional
> choice or control?
> 

Hi Drew,
   You might be comfortable with Emacs undo. What is your opinion on
   new users' comfort level with it ? The advantage with d-s-m
   being off is it leads to less accidental deletions, hence less need
   to undo.  I have 8000 hours of Emacs under my belt and I can manage
   only evil-mode's simplified undo/redo in spite of its weakness. 

Emacs should not half-ass the embracing of new users. Either go the
full hog - CUA, C-z undo, C-y redo (real redo), C-s save, C-a select
all, shift-selection-mode, right-click context menu.  Only then there
is any hope for the non-manual-readers.

If only d-s-m is  enabled, and there is an accidental selected text
deletion - user would try C-z : which would weirdly vanish their
window. After frantically finding the window back, they would try C-y
for redo to correct anything this C-z might have done. C-y would paste
their accidentally killed selected text at a place where their cursor
found itself while they were confused.

thanks

Re: delete-selection-mode as default

[Stefan Monnier]

> Emacs should not half-ass the embracing of new users. Either go the
> full hog - CUA, C-z undo, C-y redo (real redo), C-s save, C-a select
> all, shift-selection-mode, right-click context menu.  Only then there
> is any hope for the non-manual-readers.

There are two separate issues:
1- what is the best UI (according to us)
2- what we should do for new users

As maintainer, I used (1) rather than (2) as my guide to choose the
default settings.

Whether the best UI has d-s-m enabled or disabled is under discussion.
My opinion is that regarding point (1) d-s-m doesn't matter much: both
choices are about equally good.  So I'd favor enabling it (after fixing
its implementation) on the grounds that it's what other UIs do.

But just because for this particular choice, I/we end up deciding of the
default value based on (2), that doesn't mean that it should be the case
for everything else.


        Stefan

Re: delete-selection-mode as default

[hw]

Drew Adams <drew.adams@oracle.com> writes:

> [...]
> The only argument I saw here (unless I've forgotten already)
> in favor of it being off (by default or not) is that when it is on
> a user (new or old) can too easily accidentally delete text.
>
> (Some added "irretrievably", but I haven't seen that claim
> supported yet.)

This is a misunderstanding.  You need to distinguish between the
selection itself and the contents of the selection.  The contents
usually aren't likely to get lost forever.

The selection itself *is* lost irretrievably when you make a movement
without holding the key (like Shift or Ctrl) you need to press to
select.  So far, I've never seen a software that had an undo for this,
and it has annoyed me many times.

It's another example for the design flaw of making a mistake worse
rather than protecting the user from it.

> [...]
> So again, what's the advantage to it being off? (It's not a
> rhetorical question.) Is there really some useful "option"
> that its being off offers? Does that give you additional
> choice or control?

That depends on what you consider as "off".

Under "normal" circumstances, "off" seems to mean that backspace deletes
a region only when it is active, and that other keystrokes tend to
deactivate an active region before they insert themselves into the
buffer.

That means it's not really off.  If it was really off, backspace would
not delete a region when it's active, and other keystrokes would
neither deactivate an active region, nor insert themselves into the
buffer, but they would make Emacs beep.

So "really off" would give the user maximum protection against mistakes
that could otherwise lead to loosing the selection itself, its contents
or both.  That is an advantage.

The other advantage is that users may be glad to see a behaviour which
they end up finding better and might have never discovered if it wasn't
the default.  When more users appreciate it, they might urge the
developers of other software to implement something similar.


In any case, the whole concept of regions could use an overhaul.

Re: delete-selection-mode as default (WAS: Some developement questions)

[Alan Mackenzie]

Hello, Drew.

On Sun, Sep 09, 2018 at 15:24:30 -0700, Drew Adams wrote:
> I agree that a poll of this list is not a great guide (for this question
> and many others).

> > Two questions should be considered: a) "Would leaving it off scare
> > away potential new users?" and b) "Would turning it on obscure an
> > option that is potentially useful to at least a subset of new users?"

> I must have missed what that potentially useful option is.

The option is having delete-selection-mode turned off, which is a useful
option in itself.

Actually, I'm not sure what the use of d-s-mode actually is.  I don't
recall anyone here advocating it on some intrinsic merits, only "because
everybody else does it", which I've never found a convincing argument for
anything in Emacs.

> > On the other hand, if `delete-selection-mode` is on by default,
> > most, if not all, new users will never even consider the
> > possibility that Emacs has the option to disable it and that
> > that might actually fit their workflow better.

> This too hints at some advantage to having it off.

> The only argument I saw here (unless I've forgotten already)
> in favor of it being off (by default or not) is that when it is on
> a user (new or old) can too easily accidentally delete text.

> (Some added "irretrievably", but I haven't seen that claim
> supported yet.)

That was me, the complete phrase was "irretrievably lost" and I carefully
outlined what was being lost and where.  In summary, it was a carefully
and painstakingly constructed region, and what was being lost by a
careless movement key without <shift> was the point and mark of the
highlighted region, not its contents.  Furthermore it was in programs
which aren't Emacs.

> That advantage would seem to be something that would
> most benefit new users, no? But the claim has been that
> new users are more used to the on, not the off, behavior.

> So again, what's the advantage to it being off? (It's not a
> rhetorical question.) Is there really some useful "option"
> that its being off offers? Does that give you additional
> choice or control?

Yes.  It enables you to type onto the end of a (highlighted) region
without being distracted by first having to do something to remove the
highlighting, or more likely without first having to use `undo' to get
your region back again, followed by unhighlighting it followed by typing
the character you want to append.

Personally, it scarcely affects me because I run with transient-mark-mode
disabled, but I still occasionally get unwanted highlighting of regions
for some reason.

-- 
Alan Mackenzie (Nuremberg, Germany).

RE: delete-selection-mode as default (WAS: Some developement questions)

[Drew Adams]

> Actually, I'm not sure what the use of d-s-mode actually is.  I don't
> recall anyone here advocating it on some intrinsic merits, only "because
> everybody else does it", which I've never found a convincing argument for
> anything in Emacs.

Minor convenience. If the region is active then typing or
yanking replaces it - no need to use `C-w' first. That's all.
Not a big deal either way, IMO (as Stefan has said).

When the region is active you can do things to it or with it.
Otherwise, there is _no reason to activate it_.

If it is active, one of the things you often want to do with
it is delete it or replace it. We tend to do that often, and
d-s-m mode makes that easier/quicker. Nothing more.

Think of overwrite mode (bound to <insert>) versus inserting
and having to use `C-d' before or after each char you type.

No, of course you wouldn't use `C-d' for each char, but
that's the idea. The more often you had to compensate for
insertion by deleting what was there beforehand, the more
you might find overwrite mode handy.

If you often replace selected text then not bothering to use
`C-w' first can be handy. Select some text, then type or yank
to replace it.

> That was me, the complete phrase was "irretrievably lost" and I carefully
> outlined what was being lost and where.  In summary, it was a carefully
> and painstakingly constructed region, and what was being lost by a
> careless movement key without <shift> was the point and mark of the
> highlighted region, not its contents.  Furthermore it was in programs
> which aren't Emacs.

I see. I never use shift-selection. Dunno whether that's relevant -
probably not.

> It enables you to type onto the end of a (highlighted) region
> without being distracted by first having to do something to remove the
> highlighting, 

Yes. If someone doesn't want to do something to/with the
active region then it shouldn't be active. `C-g' deactivates it.

In a way, d-s-m or not d-s-m is a bit about C-g versus C-w.
Which do you need to use more often, C-w (without d-s-m)
or C-g (with d-s-m). That might be one way of looking at
the choice people make.

> or more likely without first having to use `undo' to get
> your region back again, followed by unhighlighting it followed by typing
> the character you want to append.

You shouldn't be losing the region in the first place. You
shouldn't need to undo or unhighlight. If you accidentally
activated the region, and you want to deactivate it, C-g
should take care of that.

I'm guessing this comes back to the `C-x C-x' activation
of the region. With that turned off, i.e., with `C-x C-x' just
swapping point and mark like it did in the old days, I'm
guessing you will never have an active region that bothers
you - with or without d-s-m. But that's just a guess.

Users should not get an active region when they don't
want it, i.e., when they don't want to act on the region.
And they should be able to easily get an active region
when they do want to act on the region.

If we're not yet supporting that well then that's where
the improvement should come first, I think.

The only time I get an active region when I don't want it
is if I activated it thinking I was going to do something
with it, and then I changed my mind (so I use C-g).

I suspect that things are very different for you, and I
suspect it is because of `C-x C-x' activating the region
even though you have no intention of acting on it.

An active region is perhaps more of a bother than an aid,
for someone who never (or rarely) wants to act on it.

I feel like region activation by `C-x C-x' was maybe foisted
on people who never wanted or expected to do anything
with an active region. If so, they've probably been silently
tolerating it all these years. And yes, I can see why, if that's
the case, they might dread moving to d-s-m.

I think we've finally identified the real problem underlying
such anxiety as being region activation by `C-x C-x'. Take that
away and I think folks who don't want to use d-s-m will be fine.

For folks who do want to use d-s-m, region activation
by `C-x C-x' is handy. But it's not necessary. In any case,
region activation has nothing inherently to do with
swapping point and mark.

Maybe someone who detests d-s-m could spend a few minutes
with it turned on but with `C-x C-x' bound to a command that
just swaps point and mark without activating the region. My
guess is that if that were the default behavior it might be OK
for most people.

D-s-m, but without Emacs activating the region each time you
use `C-x C-x'. No undesired region activation, so no unexpected
d-s-m action.

And of course, for someone who really wants to take advantage
of d-s-m we still would offer the current, region-activating
`C-x C-x' command. But we should also offer a command that
just activates the region, nothing more. By default that would be
unbound (or at most bound to something other than `C-x C-x').

> Personally, it scarcely affects me because I run with transient-mark-mode
> disabled, 

There you go. That's probably the right thing to do for
someone who doesn't want d-s-m behavior. But then
do you have to monkey around with temporary t-m-m,
or do you just not bother, ever, with having an active
region? I'm guessing the latter.

> but I still occasionally get unwanted highlighting of regions
> for some reason.

Probably from accidental temporary t-m-m, would be
my guess. (That's something else I never use.)

Or maybe from some other commands that activate the
region? I think that if t-m-m is off then most commands
(e.g. query-replace) do not try to activate the region
(which is correct behavior - an active region makes
sense only for t-m-m/d-s-m).

In sum, having d-s-m + t-m-m both on is good for folks
like me. Having them both off is maybe good for folks
like you.

Having t-m-m on and d-s-m off might not be the best
thing. But that's the default behavior.

Re: delete-selection-mode as default

[hw]

Drew Adams <drew.adams@oracle.com> writes:

> [...]
>
> Users should not get an active region when they don't
> want it, i.e., when they don't want to act on the region.
> And they should be able to easily get an active region
> when they do want to act on the region.

Highlighting regions should be separated from whether they are active or
not, and I don't want hidden regions, either.

Currently even when a region is not active (it is a hidden region
because it is not highlighted), you can do something with it, so users
always get an "active" region even when they don't want one.  It's only
a bit less active than it is when it is highlighted.

> [...]
> I suspect that things are very different for you, and I
> suspect it is because of `C-x C-x' activating the region
> even though you have no intention of acting on it.

Exchanging point and mark is a purely navigational thing, and somehow
the activation and deactivation of hidden(!) regions which may have been
modified because point may have moved since a region was selected last
time(!) has been mixed into that.  That is ill advised.

> [...]
> I feel like region activation by `C-x C-x' was maybe foisted
> on people who never wanted or expected to do anything
> with an active region.

Do you mean they would rather do things with hidden regions?  I never
want to do that.

> In any case, region activation has nothing inherently to do with
> swapping point and mark.

Right, so why not separate navigational functions from highlighting and
regions?

Use point and mark purely for navigation, set a selection-start-marker
with C-spc and a selection-end-marker with another C-spc (or whatever
key binding is appropriate for it).  The region is between these
markers, and you can have multiple regions in the same buffer.  Do
something with a region, and its markers are forgotten unless you use a
prefix.  Have a key binding to jump around between the regions in a
buffer, and you can tell Emacs with which of them you want to do
something by moving point into it.  If you want to do the same thing
with multiple regions, move point into one after another and make them
"sticky" for operation, or mark them right after selecting them.

That might make a lot of things much simpler, and we wouldn't have to
feel uneasy about the hidden regions all the time.

> [...]
> There you go. That's probably the right thing to do for
> someone who doesn't want d-s-m behavior. But then
> do you have to monkey around with temporary t-m-m,
> or do you just not bother, ever, with having an active
> region? I'm guessing the latter.

It can make it difficult to do things supposed to be limited to a
region.  I might disable t-m-m if I could see what I have selected with
it disabled and monkey.  I never use C-x C-x, so it doesn't make a
difference otherwise, which leaves nothing but disadvantages to having
t-m-m disabled.

> [...]

RE: delete-selection-mode as default

[Drew Adams]

> Highlighting regions should be separated from whether they are active or
> not, and I don't want hidden regions, either.

There are ways to highlight the region without activating it.
You can use one of those (preferably with a different face,
if you also sometimes use an active region)..

But it's important to highlight the active region.

> Currently even when a region is not active (it is a hidden region
> because it is not highlighted), you can do something with it, so users
> always get an "active" region even when they don't want one.  It's only
> a bit less active than it is when it is highlighted.

The "active region" has a well-defined meaning in Emacs.
Don't confuse things by talking about how you can act on
the region when it is not active in the usual sense.

> > I feel like region activation by `C-x C-x' was maybe foisted
> > on people who never wanted or expected to do anything
> > with an active region.
> 
> Do you mean they would rather do things with hidden regions?  I never
> want to do that.

Not clear, but it sounds like you do want an active region, in the usual
sense, but you want it to be active for only some things, none of which
are type/paste to replace/delete.

> Use point and mark purely for navigation, set a selection-start-marker
> with C-spc and a selection-end-marker with another C-spc (or whatever
> key binding is appropriate for it).  The region is between these
> markers, and you can have multiple regions in the same buffer.  Do
> something with a region, and its markers are forgotten unless you use a
> prefix.  Have a key binding to jump around between the regions in a
> buffer, and you can tell Emacs with which of them you want to do
> something by moving point into it.  If you want to do the same thing
> with multiple regions, move point into one after another and make them
> "sticky" for operation, or mark them right after selecting them.

Much of what you describe is available with various libraries, including
`zones.el' (https://www.emacswiki.org/emacs/Zones).

Re: delete-selection-mode as default

[hw]

Drew Adams <drew.adams@oracle.com> writes:

>> Highlighting regions should be separated from whether they are active or
>> not, and I don't want hidden regions, either.
>
> There are ways to highlight the region without activating it.
> You can use one of those (preferably with a different face,
> if you also sometimes use an active region)..

I'm not sure if that is very useful unless there are multiple regions.

> But it's important to highlight the active region.

yes

>> Currently even when a region is not active (it is a hidden region
>> because it is not highlighted), you can do something with it, so users
>> always get an "active" region even when they don't want one.  It's only
>> a bit less active than it is when it is highlighted.
>
> The "active region" has a well-defined meaning in Emacs.
> Don't confuse things by talking about how you can act on
> the region when it is not active in the usual sense.

That the meaning of "active region" is well defined doesn't seem to
prevent inconsistency and confusion.

Are there multiple senses in which a region can be active? ;)

>> > I feel like region activation by `C-x C-x' was maybe foisted
>> > on people who never wanted or expected to do anything
>> > with an active region.
>> 
>> Do you mean they would rather do things with hidden regions?  I never
>> want to do that.
>
> Not clear, but it sounds like you do want an active region, in the usual
> sense, but you want it to be active for only some things, none of which
> are type/paste to replace/delete.

What I usually do with a region is stuff with it ... i. e. cut/copy and
paste it, and I use it to limit (not extend) the effect of functions
like query-replace.  I also use indent-region, but that always works
with a region --- you could see some inconsistency here, too, because
with an active region, only indent would be needed which is limited to a
region that is active and otherwise work with the whole buffer.
Sometimes I use it for whitespace-cleanup, which is also limited to an
active region --- another inconsistency is whitespace-cleanup-region.

There may be other things I use regions for that doesn't come to mind
atm.  It might be wrong to call them regions because it's no more than a
selection to me.

I select a region when I want one and expect it to be forgotten once I
did something with it.  I do not want hidden regions lurking invisibly
in the background, waiting for me to make a mistake so they can suddenly
come out of hiding and bite me.

Regions do not have anything to do with navigation, and I don't use them
for that.

I would prefer consistency and selections to act like I want them to,
like no delete-selection-mode, no shift-selection, no deletion of
regions by arbitrary keystrokes, no de-activating regions by arbitrary
keystrokes ...

I don't really care about transient-mark-mode.  I enabled it a long time
ago because with it enabled, selections get finally highlighted like
they should be.  When I made a selection, it is only logical that
functions are limited to the selection, so this special feature of t-m-m
isn't a special feature to me.  And how would you limit functions to
selections otherwise?

Whether functions are limited to a selection doesn't have anything to do
with how the selection has been made, i. e. whether with t-m-m enabled
or disabled.  It also doesn't have anything to do with whether a
selection is highlighted or not, but when something is selected, it
should be highlighted, and when something isn't highlighted, it
shouldn't be selected.

There are so things entirely unrelated of each other that I now have
lost count.  Only Emacs makes a mess of them and even throws navigation
into the mess.

Extending functions to a selection is yet an entirely different
issue. You can only limit functions that otherwise work with the whole
buffer to a region, and you can only extend functions that do not work
with a whole buffer to a region.  Transient-mark-mode is supposed to
limit functions, not to extend them.  To extend functions, a separate
mode may be helpful (like you already have d-s-m).

>> Use point and mark purely for navigation, set a selection-start-marker
>> with C-spc and a selection-end-marker with another C-spc (or whatever
>> key binding is appropriate for it).  The region is between these
>> markers, and you can have multiple regions in the same buffer.  Do
>> something with a region, and its markers are forgotten unless you use a
>> prefix.  Have a key binding to jump around between the regions in a
>> buffer, and you can tell Emacs with which of them you want to do
>> something by moving point into it.  If you want to do the same thing
>> with multiple regions, move point into one after another and make them
>> "sticky" for operation, or mark them right after selecting them.
>
> Much of what you describe is available with various libraries, including
> `zones.el' (https://www.emacswiki.org/emacs/Zones).

... like you describe in your other post, thanks!  I need to look into
that.

Re: delete-selection-mode as default

[Alan Mackenzie]

Hello, hw.

On Wed, Sep 12, 2018 at 00:34:11 +0200, hw wrote:
> Drew Adams <drew.adams@oracle.com> writes:

> Highlighting regions should be separated from whether they are active
> or not, and I don't want hidden regions, either.

I do.  I want point and mark, and the region between them to be regarded
as "the" region.  That's it.  I currently (almost) have that option.

> Currently even when a region is not active (it is a hidden region
> because it is not highlighted), you can do something with it, so users
> always get an "active" region even when they don't want one.  It's only
> a bit less active than it is when it is highlighted.

As I've pointed out several times in the distant past, the terminology
used for things in this part of Emacs is thoroughly suboptimal.  A region
is never "active"; it never does anything, it is never an agent.  For
example.

> > [...]
> > I suspect that things are very different for you, and I
> > suspect it is because of `C-x C-x' activating the region
> > even though you have no intention of acting on it.

> Exchanging point and mark is a purely navigational thing, and somehow
> the activation and deactivation of hidden(!) regions ....

There's exactly one region, except when there's none (before the mark has
been set in a buffer).

> .... which may have been modified because point may have moved since a
> region was selected last time(!) has been mixed into that.  That is ill
> advised.

No, it's central and essential to how Emacs works.  There is ONE region,
the part of the buffer between mark and point.  Let's not muck around
with this.

> > I feel like region activation by `C-x C-x' was maybe foisted
> > on people who never wanted or expected to do anything
> > with an active region.

> Do you mean they would rather do things with hidden regions?  I never
> want to do that.

I do.  I don't want my region highlighted, ever.

> Right, so why not separate navigational functions from highlighting and
> regions?

> Use point and mark purely for navigation, set a selection-start-marker
> with C-spc and a selection-end-marker with another C-spc (or whatever
> key binding is appropriate for it).  The region is between these
> markers, and you can have multiple regions in the same buffer.  Do
> something with a region, and its markers are forgotten unless you use a
> prefix.  Have a key binding to jump around between the regions in a
> buffer, and you can tell Emacs with which of them you want to do
> something by moving point into it.  If you want to do the same thing
> with multiple regions, move point into one after another and make them
> "sticky" for operation, or mark them right after selecting them.

> That might make a lot of things much simpler, and we wouldn't have to
> feel uneasy about the hidden regions all the time.

Simpler?  You've got to be kidding!  Who really wants to have several
regions, and why?  I think the times one would want several regions would
be so rare as to be pure unjustified complexity.

> > [...]
> > There you go. That's probably the right thing to do for
> > someone who doesn't want d-s-m behavior. But then
> > do you have to monkey around with temporary t-m-m,
> > or do you just not bother, ever, with having an active
> > region? I'm guessing the latter.

> It can make it difficult to do things supposed to be limited to a
> region.  I might disable t-m-m if I could see what I have selected with
> it disabled and monkey.

Monkey?

One of the uses of C-x C-x is to check what is currently in the region.
Typically, you'd type it twice, to get back to your starting point.

> I never use C-x C-x, so it doesn't make a difference otherwise, which
> leaves nothing but disadvantages to having t-m-m disabled.

There are many advantages to having transient-mark-mode disabled:
primarily simplicity, and the severe reduction in the modal behaviour (in
the sense of key sequences doing different things in things like vi's
insert mode and command mode).  And I'm not happy having my font-locking
splatted by the region's highlighting.

But everybody's different here, with different preferences, likes, hates.
It's a mistake (which I've made quite a few times) to assume that
"obvious" options in Emacs actually are obvious.

-- 
Alan Mackenzie (Nuremberg, Germany).

RE: delete-selection-mode as default

[Drew Adams]

> > Currently even when a region is not active (it is a hidden region
> > because it is not highlighted), you can do something with it, so users
> > always get an "active" region even when they don't want one.  It's only
> > a bit less active than it is when it is highlighted.
> 
> As I've pointed out several times in the distant past, the terminology
> used for things in this part of Emacs is thoroughly suboptimal.  A region
> is never "active"; it never does anything, it is never an agent.  For
> example.

OK. Perhaps a better term for it would have been "activated", not "active".

And yes, a region is always activated (or enabled or able to be acted) on,
in multiple ways. Someone picked a term for a region being activated for
certain kinds of action. Some term for what is meant by that is useful -
some term beyond just "highlighted" or "selected".

"Active region" is OK, I think. Anyway, it's what we've been using, and I
don't think it's awfully confusing, even if it can be a bit misleading.

> One of the uses of C-x C-x is to check what is currently in the region.
> Typically, you'd type it twice, to get back to your starting point.

More exactly, one of the uses of C-x C-x _highlighting_ is that. You want
a visual indication of the limits of the region, and perhaps of all of its
contents. The other thing that C-x C-x does is activate the region, and
in your case you do not need/want that.

> There are many advantages to having transient-mark-mode disabled:
> primarily simplicity, and the severe reduction in the modal behaviour (in
> the sense of key sequences doing different things in things like vi's
> insert mode and command mode).  And I'm not happy having my font-locking
> splatted by the region's highlighting.

Being able to apply some actions to the region (or being unable to do
so) is just a thing. It can be limiting, as you suggest. But it can also be
handy - depending on the user and what s?he wants to do.

Just as `delete-selection-mode' provides essentially an implicit
C-w, which can be either a convenience or a bother, depending,
so can isolating the region for acting on it, but just highlighting
it instead of narrowing to it (so you can still see the surrounding
context) be either a  convenience or a bother, depending.

I like to have (and use) both, at different times: (1) narrowing to
the region to act on it and (2) activating the region to act on it.

My `isearch+.el' lets me limit Isearch to the active region, for
instance, but still see the surrounding context. Do I always use
that, instead of narrowing and then searching? No. I do both,
at different times. I like having the option to do either.

> But everybody's different here, with different preferences, likes, hates.
> It's a mistake (which I've made quite a few times) to assume that
> "obvious" options in Emacs actually are obvious.

100% agreement on that. And the preferences of the same
user can even change over time and as new possibilities arise.

Re: delete-selection-mode as default

[Alan Mackenzie]

Hello, Drew.

On Wed, Sep 12, 2018 at 06:41:43 -0700, Drew Adams wrote:

[ .... ]

> > One of the uses of C-x C-x is to check what is currently in the
> > region.  Typically, you'd type it twice, to get back to your
> > starting point.

> More exactly, one of the uses of C-x C-x _highlighting_ is that.

No, I meant what I wrote.  Even without the highlighting, the first C-x
C-x takes point to the other end of the region.  You thus see where it
is.

> You want a visual indication of the limits of the region, ....

This is exactly what I don't want.  This visual indication would get in
my way.

> .... and perhaps of all of its contents. The other thing that C-x C-x
> does is activate the region, and in your case you do not need/want
> that.

Yes.

> > There are many advantages to having transient-mark-mode disabled:
> > primarily simplicity, and the severe reduction in the modal
> > behaviour (in the sense of key sequences doing different things in
> > things like vi's insert mode and command mode).  And I'm not happy
> > having my font-locking splatted by the region's highlighting.

> Being able to apply some actions to the region (or being unable to do
> so) is just a thing. It can be limiting, as you suggest. But it can
> also be handy - depending on the user and what s?he wants to do.

Yes.  I was countering hw's assertion that running with
transient-mark-mode disabled was not sensible.

[ .... ]

> > But everybody's different here, with different preferences, likes,
> > hates.  It's a mistake (which I've made quite a few times) to assume
> > that "obvious" options in Emacs actually are obvious.

> 100% agreement on that. And the preferences of the same user can even
> change over time and as new possibilities arise.

Even that, yes.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: delete-selection-mode as default

[Yuri Khan]

On Wed, Sep 12, 2018 at 8:19 PM Alan Mackenzie <acm@muc.de> wrote:

> And I'm not happy having my font-locking
> splatted by the region's highlighting.

It’s not splatted with careful face customization. Namely, customize
the ‘region’ face to not specify :foreground but only :background, a
shade or tint very close to but distinct from your normal background.
May also need to set :distant-foreground to 'unspecified.

Example: my ‘default’ face is :foreground "#b3b3b4" :background
"#414042" (light gray on dark gray), and my ‘region’ is :background
"#4d4d4f" (slightly lighter but still fairly dark gray). All syntax
highlighting faces are still visible against this background. I avoid
changing background color alone for syntax highlighting.

Re: delete-selection-mode as default

[Alan Mackenzie]

Hello, Yuri.

On Wed, Sep 12, 2018 at 22:51:49 +0700, Yuri Khan wrote:
> On Wed, Sep 12, 2018 at 8:19 PM Alan Mackenzie <acm@muc.de> wrote:

> > And I'm not happy having my font-locking
> > splatted by the region's highlighting.

> It’s not splatted with careful face customization. Namely, customize
> the ‘region’ face to not specify :foreground but only :background, a
> shade or tint very close to but distinct from your normal background.
> May also need to set :distant-foreground to 'unspecified.

Thanks for the suggestion, but...  When I said "my font-locking", I
meant _MY_ font-locking.  I run Emacs on a Linux virtual terminal, which
has 16 colours altogether.  The only useful thing I could customize the
region face to would be a null face, but then I would have no warning of
the region becoming "active".  Currently the region face is a solid dark
blue background, which obliterates all other uses of highlighting on the
screen.

> Example: my ‘default’ face is :foreground "#b3b3b4" :background
> "#414042" (light gray on dark gray), and my ‘region’ is :background
> "#4d4d4f" (slightly lighter but still fairly dark gray). All syntax
> highlighting faces are still visible against this background. I avoid
> changing background color alone for syntax highlighting.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: delete-selection-mode as default

[Yuri Khan]

On Wed, Sep 12, 2018 at 11:02 PM Alan Mackenzie <acm@muc.de> wrote:

> Thanks for the suggestion, but...  When I said "my font-locking", I
> meant _MY_ font-locking.  I run Emacs on a Linux virtual terminal, which
> has 16 colours altogether.  The only useful thing I could customize the
> region face to would be a null face, but then I would have no warning of
> the region becoming "active".  Currently the region face is a solid dark
> blue background, which obliterates all other uses of highlighting on the
> screen.

Well, yes, your setup imposes severe limitations. Even then, I think
black normal background and blue region background (or vice versa)
would be usable.

Re: delete-selection-mode as default

[Elias Mårtenson]

[-- Attachment #1: Type: text/plain, Size: 759 bytes --]

On Wed, 12 Sep 2018 at 21:20, Alan Mackenzie <acm@muc.de> wrote:

On Wed, Sep 12, 2018 at 00:34:11 +0200, hw wrote:
> > Drew Adams <drew.adams@oracle.com> writes:
>
> > Highlighting regions should be separated from whether they are active
> > or not, and I don't want hidden regions, either.
>
> I do.  I want point and mark, and the region between them to be regarded
> as "the" region.  That's it.  I currently (almost) have that option.
>

Thank you for saying this. I agree with you 100%, and the overloading of
the region concept into something that does multiple different things while
at the same time dismantles the beautiful simplicity and power of the “one
region at all times” concept is disheartening to me.

Regards,
Elias

[-- Attachment #2: Type: text/html, Size: 1154 bytes --]

Re: delete-selection-mode as default

[hw]

Alan Mackenzie <acm@muc.de> writes:

> Hello, hw.
>
> On Wed, Sep 12, 2018 at 00:34:11 +0200, hw wrote:
>> Drew Adams <drew.adams@oracle.com> writes:
>
>> Highlighting regions should be separated from whether they are active
>> or not, and I don't want hidden regions, either.
>
> I do.  I want point and mark, and the region between them to be regarded
> as "the" region.  That's it.  I currently (almost) have that option.

How do I get the region highlighted so I can see where it is?

>> Currently even when a region is not active (it is a hidden region
>> because it is not highlighted), you can do something with it, so users
>> always get an "active" region even when they don't want one.  It's only
>> a bit less active than it is when it is highlighted.
>
> As I've pointed out several times in the distant past, the terminology
> used for things in this part of Emacs is thoroughly suboptimal.  A region
> is never "active"; it never does anything, it is never an agent.  For
> example.

Maybe "workable" is a better term.

>> > [...]
>> > I suspect that things are very different for you, and I
>> > suspect it is because of `C-x C-x' activating the region
>> > even though you have no intention of acting on it.
>
>> Exchanging point and mark is a purely navigational thing, and somehow
>> the activation and deactivation of hidden(!) regions ....
>
> There's exactly one region, except when there's none (before the mark has
> been set in a buffer).

There shouldn't be one unless it's highlighted.  If highlighted, it
depends on how you consider it:  multiple regions, or still one region
which is non-consecutive.

>> .... which may have been modified because point may have moved since a
>> region was selected last time(!) has been mixed into that.  That is ill
>> advised.
>
> No, it's central and essential to how Emacs works.  There is ONE region,
> the part of the buffer between mark and point.  Let's not muck around
> with this.

Then how come I can't even see where the mark is, let alone the region?
Why is that not displayed?

>> > I feel like region activation by `C-x C-x' was maybe foisted
>> > on people who never wanted or expected to do anything
>> > with an active region.
>
>> Do you mean they would rather do things with hidden regions?  I never
>> want to do that.
>
> I do.  I don't want my region highlighted, ever.

Why not?  When highlighting screws up your syntax highlighting, maybe a
different way of highlighting could help.  Even only marking the fringes
of lines that are selected would be better than nothing.

How do you limit functions to a part of a buffer when you do not use
transient-mark-mode?

>> Right, so why not separate navigational functions from highlighting and
>> regions?
>
>> Use point and mark purely for navigation, set a selection-start-marker
>> with C-spc and a selection-end-marker with another C-spc (or whatever
>> key binding is appropriate for it).  The region is between these
>> markers, and you can have multiple regions in the same buffer.  Do
>> something with a region, and its markers are forgotten unless you use a
>> prefix.  Have a key binding to jump around between the regions in a
>> buffer, and you can tell Emacs with which of them you want to do
>> something by moving point into it.  If you want to do the same thing
>> with multiple regions, move point into one after another and make them
>> "sticky" for operation, or mark them right after selecting them.
>
>> That might make a lot of things much simpler, and we wouldn't have to
>> feel uneasy about the hidden regions all the time.
>
> Simpler?  You've got to be kidding!  Who really wants to have several
> regions, and why?  I think the times one would want several regions would
> be so rare as to be pure unjustified complexity.

One reason is visual indication.  I can set a register or a bookmark in
a buffer and never see it, or I can write 'FIXME:' comments which is
silly when I'm working on something so that it's gona be fixed anyway,
and hard to see --- or I could highlight the lines I'm concerned about
and need to look into.  If I could highlight parts, I could go through
the source and read it, which I do anyway, highlight the relevant places
and have it much easier to move around and to find things and not
overlook something.  It could be a big relieve because I don't need to
remember so much all at the same time because I could just see it
highlighted.

If it wouldn't screw up regions and do what ever hidden stuff, I might
even use the mark for navigation, so navigating would be easier in two
ways.

>> > [...]
>> > There you go. That's probably the right thing to do for
>> > someone who doesn't want d-s-m behavior. But then
>> > do you have to monkey around with temporary t-m-m,
>> > or do you just not bother, ever, with having an active
>> > region? I'm guessing the latter.
>
>> It can make it difficult to do things supposed to be limited to a
>> region.  I might disable t-m-m if I could see what I have selected with
>> it disabled and monkey.
>
> Monkey?

... around with temporary t-m-m to limit functions to selections.

> One of the uses of C-x C-x is to check what is currently in the region.
> Typically, you'd type it twice, to get back to your starting point.

Why would I?

>> I never use C-x C-x, so it doesn't make a difference otherwise, which
>> leaves nothing but disadvantages to having t-m-m disabled.
>
> There are many advantages to having transient-mark-mode disabled:
> primarily simplicity, and the severe reduction in the modal behaviour (in
> the sense of key sequences doing different things in things like vi's
> insert mode and command mode).  And I'm not happy having my font-locking
> splatted by the region's highlighting.

Any simplicity here is no more than a deceptive apparition.

It's not like I like transient-mark-mode, it's only the least evil.  The
concept of "the" region and having it all messed up with each other is
what's really evil.

I want my selection highlighted.  I'd also need to have regions and
selections decoupled from the navigation.  There's no sense in "the"
region.  I don't need a region to navigate.  I don't need a region for a
selection.  I need to navigate and to select, independently of each
other, and I especially don't need "the" lurking hidden region to screw
things up for me because it's coupled to everything.

> But everybody's different here, with different preferences, likes, hates.
> It's a mistake (which I've made quite a few times) to assume that
> "obvious" options in Emacs actually are obvious.

Is there anything obvious about Emacs? :)

Re: delete-selection-mode as default

[Alan Mackenzie]

Hello, hw.

On Thu, Sep 13, 2018 at 06:16:24 +0200, hw wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > On Wed, Sep 12, 2018 at 00:34:11 +0200, hw wrote:
> >> Drew Adams <drew.adams@oracle.com> writes:

> >> Highlighting regions should be separated from whether they are active
> >> or not, and I don't want hidden regions, either.

> > I do.  I want point and mark, and the region between them to be regarded
> > as "the" region.  That's it.  I currently (almost) have that option.

> How do I get the region highlighted so I can see where it is?

You can't, as far as I'm aware, except by using transient-mark-mode.  If
you want such a facility, implement it!

> > There's exactly one region, except when there's none (before the mark has
> > been set in a buffer).

> There shouldn't be one unless it's highlighted.  If highlighted, it
> depends on how you consider it:  multiple regions, or still one region
> which is non-consecutive.

Don't confuse your personal preferences with objective things.  We all
use Emacs differently, which is why it is so customisable.  If you can't
customise it to work the way you want, that is likely a bug, which you
should feel free to fix.

[ .... ]

> > No, it [the mark]'s central and essential to how Emacs works.  There
> > is ONE region, the part of the buffer between mark and point.  Let's
> > not muck around with this.

> Then how come I can't even see where the mark is, let alone the region?
> Why is that not displayed?

Because this was tried and found counter-productive.

> >> Do you mean they would rather do things with hidden regions?  I never
> >> want to do that.

> > I do.  I don't want my region highlighted, ever.

> Why not?

Personal preference.

> When highlighting screws up your syntax highlighting, maybe a different
> way of highlighting could help.  Even only marking the fringes of lines
> that are selected would be better than nothing.

I prefer nothing, thanks.  Would you want to make my preferred way of
working impossible?

> How do you limit functions to a part of a buffer when you do not use
> transient-mark-mode?

By narrowing.  C-x n n narrows to the region.  C-x n w widens to the
entire buffer.  C-x n d narrows to the current source code function.  Try
it!  Look it up in the Emacs manual (e.g., with C-i narrowing).

[ .... ]

> > Who really wants to have several regions, and why?  I think the times
> > one would want several regions would be so rare as to be pure
> > unjustified complexity.

> One reason is visual indication.  I can set a register or a bookmark in
> a buffer and never see it, or I can write 'FIXME:' comments which is
> silly when I'm working on something so that it's gona be fixed anyway,
> and hard to see --- or I could highlight the lines I'm concerned about
> and need to look into.  If I could highlight parts, I could go through
> the source and read it, which I do anyway, highlight the relevant places
> and have it much easier to move around and to find things and not
> overlook something.  It could be a big relieve because I don't need to
> remember so much all at the same time because I could just see it
> highlighted.

As a matter of interest, you can easily arrange for all occurrences of
FIXME: to be highlighted, with hi-lock-mode (look it up in the manual).

> If it wouldn't screw up regions and do what ever hidden stuff, I might
> even use the mark for navigation, so navigating would be easier in two
> ways.

I suggest you try this use of the mark anyway.

[ .... ]

> > Monkey?

> ... around with temporary t-m-m to limit functions to selections.

Ah!

> > One of the uses of C-x C-x is to check what is currently in the region.
> > Typically, you'd type it twice, to get back to your starting point.

> Why would I?

Then you see for sure where mark is.  It's an alternative to having the
region highlighted, which might work for you, it might not.

> >> I never use C-x C-x, so it doesn't make a difference otherwise, which
> >> leaves nothing but disadvantages to having t-m-m disabled.

> > There are many advantages to having transient-mark-mode disabled:
> > primarily simplicity, and the severe reduction in the modal behaviour (in
> > the sense of key sequences doing different things in things like vi's
> > insert mode and command mode).  And I'm not happy having my font-locking
> > splatted by the region's highlighting.

> Any simplicity here is no more than a deceptive apparition.

:-)  No, the simplicity is real.

> It's not like I like transient-mark-mode, it's only the least evil.  The
> concept of "the" region and having it all messed up with each other is
> what's really evil.

I dislike transient-mark-mode quite strongly.  I have the option to
disable it, which I do.  You have that option, too.  You also have the
option to extend Emacs to do what you want.

> I want my selection highlighted.  I'd also need to have regions and
> selections decoupled from the navigation.  There's no sense in "the"
> region.

There's a lot of sense in it.  Otherwise, it would have been superseded
or extended sometime over the last 40 years of Emacs's existence.

> I don't need a region to navigate.  I don't need a region for a
> selection.  I need to navigate and to select, independently of each
> other, and I especially don't need "the" lurking hidden region to screw
> things up for me because it's coupled to everything.

I do.  It works smoothly for me, and I never find things "screwing up"
for me in the way you're depicting.

> > But everybody's different here, with different preferences, likes, hates.
> > It's a mistake (which I've made quite a few times) to assume that
> > "obvious" options in Emacs actually are obvious.

> Is there anything obvious about Emacs? :)

Yes, lots of things.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: delete-selection-mode as default

[hw]

Alan Mackenzie <acm@muc.de> writes:

> Hello, hw.
>
> On Thu, Sep 13, 2018 at 06:16:24 +0200, hw wrote:
>> Alan Mackenzie <acm@muc.de> writes:
>
>> > On Wed, Sep 12, 2018 at 00:34:11 +0200, hw wrote:
>> >> Drew Adams <drew.adams@oracle.com> writes:
>
>> >> Highlighting regions should be separated from whether they are active
>> >> or not, and I don't want hidden regions, either.
>
>> > I do.  I want point and mark, and the region between them to be regarded
>> > as "the" region.  That's it.  I currently (almost) have that option.
>
>> How do I get the region highlighted so I can see where it is?
>
> You can't, as far as I'm aware, except by using transient-mark-mode.  If
> you want such a facility, implement it!

What is the point of being forced to make hidden selections?  I don't
know how to implement highlighting selections.

>> > There's exactly one region, except when there's none (before the mark has
>> > been set in a buffer).
>
>> There shouldn't be one unless it's highlighted.  If highlighted, it
>> depends on how you consider it:  multiple regions, or still one region
>> which is non-consecutive.
>
> Don't confuse your personal preferences with objective things.  We all
> use Emacs differently, which is why it is so customisable.  If you can't
> customise it to work the way you want, that is likely a bug, which you
> should feel free to fix.

Maybe you haven't followed the discussion, which was, amongst other
things, about what should be the default for d-s-m.  That Emacs is
customizable doesn't mean that it could be customized to deal with
selections reasonably, and as long as it can't and an overhaul of the
idea of "the region" and making selections might be in order, the
question for a the default of d-s-m can't very well be answered.

I'm merely saying how it should be, as one option, which could be a
default or not.

>
> [ .... ]
>
>> > No, it [the mark]'s central and essential to how Emacs works.  There
>> > is ONE region, the part of the buffer between mark and point.  Let's
>> > not muck around with this.
>
>> Then how come I can't even see where the mark is, let alone the region?
>> Why is that not displayed?
>
> Because this was tried and found counter-productive.

It would be very helpful and not counter productive at all.

>> >> Do you mean they would rather do things with hidden regions?  I never
>> >> want to do that.
>
>> > I do.  I don't want my region highlighted, ever.
>
>> Why not?
>
> Personal preference.
>
>> When highlighting screws up your syntax highlighting, maybe a different
>> way of highlighting could help.  Even only marking the fringes of lines
>> that are selected would be better than nothing.
>
> I prefer nothing, thanks.  Would you want to make my preferred way of
> working impossible?

No, it only doesn't make any sense to pretend that there is a selection
when there is actually none.  It gets even worse when Emacs pretends
that there is a selection when there is actually none only because the
user once had to set a mark somewhere to make a selection and would have
to kill the whole buffer to get rid of the mark and thus the pretended
selection.

>> How do you limit functions to a part of a buffer when you do not use
>> transient-mark-mode?
>
> By narrowing.  C-x n n narrows to the region.  C-x n w widens to the
> entire buffer.  C-x n d narrows to the current source code function.  Try
> it!  Look it up in the Emacs manual (e.g., with C-i narrowing).

As said, that's triple work.

> [ .... ]
>
>> > Who really wants to have several regions, and why?  I think the times
>> > one would want several regions would be so rare as to be pure
>> > unjustified complexity.
>
>> One reason is visual indication.  I can set a register or a bookmark in
>> a buffer and never see it, or I can write 'FIXME:' comments which is
>> silly when I'm working on something so that it's gona be fixed anyway,
>> and hard to see --- or I could highlight the lines I'm concerned about
>> and need to look into.  If I could highlight parts, I could go through
>> the source and read it, which I do anyway, highlight the relevant places
>> and have it much easier to move around and to find things and not
>> overlook something.  It could be a big relieve because I don't need to
>> remember so much all at the same time because I could just see it
>> highlighted.
>
> As a matter of interest, you can easily arrange for all occurrences of
> FIXME: to be highlighted, with hi-lock-mode (look it up in the manual).

It still wouldn't highlight a selection.  Hi-lock-mode doesn't have
anything to do with selections, and how would you limit functions to
what is highlighted?

>> If it wouldn't screw up regions and do what ever hidden stuff, I might
>> even use the mark for navigation, so navigating would be easier in two
>> ways.
>
> I suggest you try this use of the mark anyway.

No, why would I?

> [...]
>> > One of the uses of C-x C-x is to check what is currently in the region.
>> > Typically, you'd type it twice, to get back to your starting point.
>
>> Why would I?
>
> Then you see for sure where mark is.  It's an alternative to having the
> region highlighted, which might work for you, it might not.

You see it only indirectly, and it changes your position in the buffer,
which it shouldn't --- and when transient-mark-mode is enabled, it
highlights a part of a buffer as if there was a selection.  Nothing of
that is what I would want.  Why should I even need to do anything to
have the mark visible?

>> >> I never use C-x C-x, so it doesn't make a difference otherwise, which
>> >> leaves nothing but disadvantages to having t-m-m disabled.
>
>> > There are many advantages to having transient-mark-mode disabled:
>> > primarily simplicity, and the severe reduction in the modal behaviour (in
>> > the sense of key sequences doing different things in things like vi's
>> > insert mode and command mode).  And I'm not happy having my font-locking
>> > splatted by the region's highlighting.
>
>> Any simplicity here is no more than a deceptive apparition.
>
> :-)  No, the simplicity is real.

There is no simplicity.

>> It's not like I like transient-mark-mode, it's only the least evil.  The
>> concept of "the" region and having it all messed up with each other is
>> what's really evil.
>
> I dislike transient-mark-mode quite strongly.  I have the option to
> disable it, which I do.  You have that option, too.  You also have the
> option to extend Emacs to do what you want.

None of the options would do what I want, and making an extension that
does what I want isn't really an option, either.

Again, this stuff needs an overhaul.

>> I want my selection highlighted.  I'd also need to have regions and
>> selections decoupled from the navigation.  There's no sense in "the"
>> region.
>
> There's a lot of sense in it.  Otherwise, it would have been superseded
> or extended sometime over the last 40 years of Emacs's existence.

Then where is all that sense?

Apparently there were several attempts to change things, or there
wouldn't be t-m-m and d-s-m.

>> I don't need a region to navigate.  I don't need a region for a
>> selection.  I need to navigate and to select, independently of each
>> other, and I especially don't need "the" lurking hidden region to screw
>> things up for me because it's coupled to everything.
>
> I do.  It works smoothly for me, and I never find things "screwing up"
> for me in the way you're depicting.

Lots of things that are bad makeshift workarounds work surprisingly
smoothly, and I already said it's unlikely to make the mistake that
would reveal the design flaw because it's unlikely to press the keys for
it by accident.  That doesn't mean it's a good solution.

>> > But everybody's different here, with different preferences, likes, hates.
>> > It's a mistake (which I've made quite a few times) to assume that
>> > "obvious" options in Emacs actually are obvious.
>
>> Is there anything obvious about Emacs? :)
>
> Yes, lots of things.

Like what?

Re: delete-selection-mode as default

[Alan Mackenzie]

Hello, hw.

On Thu, Sep 13, 2018 at 22:32:58 +0200, hw wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > Hello, hw.

> > On Thu, Sep 13, 2018 at 06:16:24 +0200, hw wrote:
> >> Alan Mackenzie <acm@muc.de> writes:

> >> > On Wed, Sep 12, 2018 at 00:34:11 +0200, hw wrote:
> >> >> Drew Adams <drew.adams@oracle.com> writes:

[ .... ]

> > Don't confuse your personal preferences with objective things.  We
> > all use Emacs differently, which is why it is so customisable.  If
> > you can't customise it to work the way you want, that is likely a
> > bug, which you should feel free to fix.

> Maybe you haven't followed the discussion, which was, amongst other
> things, about what should be the default for d-s-m.  That Emacs is
> customizable doesn't mean that it could be customized to deal with
> selections reasonably, and as long as it can't and an overhaul of the
> idea of "the region" and making selections might be in order, the
> question for a the default of d-s-m can't very well be answered.

[ .... ]

> > [ .... ]

> >> > No, it [the mark]'s central and essential to how Emacs works.  There
> >> > is ONE region, the part of the buffer between mark and point.  Let's
> >> > not muck around with this.

> >> Then how come I can't even see where the mark is, let alone the region?
> >> Why is that not displayed?

> > Because this was tried and found counter-productive.

> It would be very helpful and not counter productive at all.

Please, I'm am telling you what others found by experience.

> >> When highlighting screws up your syntax highlighting, maybe a different
> >> way of highlighting could help.  Even only marking the fringes of lines
> >> that are selected would be better than nothing.

> > I prefer nothing, thanks.  Would you want to make my preferred way of
> > working impossible?

> No, it only doesn't make any sense to pretend that there is a selection
> when there is actually none.

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.

> It gets even worse when Emacs pretends that there is a selection when
> there is actually none only because the user once had to set a mark
> somewhere to make a selection and would have to kill the whole buffer
> to get rid of the mark and thus the pretended selection.

In Emacs there is the region, as I said.

[...]

> >> > There are many advantages to having transient-mark-mode disabled:
> >> > primarily simplicity, and the severe reduction in the modal
> >> > behaviour (in the sense of key sequences doing different things in
> >> > things like vi's insert mode and command mode).  And I'm not happy
> >> > having my font-locking splatted by the region's highlighting.

> >> Any simplicity here is no more than a deceptive apparition.

> > :-)  No, the simplicity is real.

> There is no simplicity.

I'm telling you my experience, I'm not making things up.  Why do you
think I disable transient-mark-mode in my Emacs, then?

[ .... ]

> None of the options would do what I want, and making an extension that
> does what I want isn't really an option, either.

Enabling transient-mark-mode and setting mark-even-if-inactive to nil
gives you what you've said you want, I think.

> Again, this stuff needs an overhaul.

I don't think you've managed to persuade anybody, certainly not me (yet).

Why are you using Emacs at all?  You seem to dislike its core concepts
and methods fairly strongly.  There are other editors available, some of
which will more closely approximate the way you want to handle
selections.  Why are you sticking with Emacs?

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: delete-selection-mode as default

[Yuri Khan]

On Fri, Sep 14, 2018 at 5:52 PM Alan Mackenzie <acm@muc.de> wrote:

> Why are you using Emacs at all?  You seem to dislike its core concepts
> and methods fairly strongly.  There are other editors available, some of
> which will more closely approximate the way you want to handle
> selections.  Why are you sticking with Emacs?

*The* core concept of Emacs as I understand it is its infinite
customizability, and this is pretty much the main reason I stick with
it.

I dislike the default Emacs keybindings, but that’s not a problem
because I can easily redefine them.

I consider the default looks of the modeline too cryptic, but that’s
not a problem because I can reconfigure it.

In my editor, I want tabs, line numbers, visible whitespace, and shift
selection. In Emacs, they all are just a few configuration options
away. (Okay, no, tabs have to be customized heavily before they are
useful for me.)

One other thing that I want is that the region be highlighted if and
only if it is going to be the target of the next command I give,
because I like to look before I leap. It seems transient-mark-mode is
intended to give me this by adding the concept of active region and
highlighting the region when it is active. However, many commands act
on the region even if it is inactive. kill-region and
copy-region-as-kill are two such commands. I am sure there are many
more, because it is much easier to write:

(defun my-command (BEGIN END)
  (interactive "r")
  ;; do something between BEGIN and END
)

than:

(defun my-command (BEGIN END)
  (interactive (if (use-region-p)
                   (list (min (point) (mark)) (max (point) (mark)))
                 ;; figure out what to do when no region is active
                 ;; * act on the whole buffer
                 ;; * act on the current narrowing
                 ;; * signal an error
                 ;; * do something else sensible
                 (list ?? ??)))
  ;; do something between BEGIN and END
)

With transient-mark-mode being the Emacs default, I’m inclined to
consider it a bug that certain commands act on the inactive region
when t-m-m is enabled, and possibly a flaw that (interactive "r")
makes it so easy to define such commands.


I was one of two people here to suggest that it is a bad thing that
the mark is used both as a navigation mechanism and as a region
delimiter, but, in practice, it would not matter much if the above
issue was addressed.

Re: delete-selection-mode as default

[Alan Mackenzie]

Hello, Yuri.

On Fri, Sep 14, 2018 at 20:41:46 +0700, Yuri Khan wrote:
> On Fri, Sep 14, 2018 at 5:52 PM Alan Mackenzie <acm@muc.de> wrote:

[ .... ]

> One other thing that I want is that the region be highlighted if and
> only if it is going to be the target of the next command I give,
> because I like to look before I leap. It seems transient-mark-mode is
> intended to give me this by adding the concept of active region and
> highlighting the region when it is active. However, many commands act
> on the region even if it is inactive. kill-region and
> copy-region-as-kill are two such commands.

You don't mention setting mark-even-if-inactive to nil.  Have you tried
this, and if so, what problems still remain with this setting?

> I am sure there are many more, .....

[ .... ]

> I was one of two people here to suggest that it is a bad thing that
> the mark is used both as a navigation mechanism and as a region
> delimiter, but, in practice, it would not matter much if the above
> issue was addressed.

This categorisation of the mark as either for navigation or for a region
delimiter, if it happened, would have to be optional.  For me, this
"double" use is a plus.  For example, quite often I do things like M->,
C-w to kill from point to EOB.  At the same time, I have no use for
transient-mark-mode, which I disable.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: delete-selection-mode as default

[Yuri Khan]

On Fri, Sep 14, 2018 at 9:06 PM Alan Mackenzie <acm@muc.de> wrote:

> You don't mention setting mark-even-if-inactive to nil.  Have you tried
> this, and if so, what problems still remain with this setting?

Thank you, this looks useful. I saw it mentioned in one of these
subthreads but did not realize it was on by default.

Re: delete-selection-mode as default

[Phil Sainty]

On 15/09/18 01:41, Yuri Khan wrote:
> I was one of two people here to suggest that it is a bad thing
> that the mark is used both as a navigation mechanism and as a
> region delimiter

I think it's impractical to suggest that all code which acts on
the region should be modified to only do so if the region is
active.

The only approach I can think of is to have the mark forcibly set
to nil whenever the region is inactive, so that commands which
want to use the region will fail.  I suspect that would mean
giving up all use of the mark ring too -- but you could implement
a custom equivalent for the purposes of navigation.


Maybe play with something like this:

(defun my-clear-inactive-mark ()
  (unless (region-active-p)
    (set-mark nil)))

(add-hook 'pre-command-hook 'my-clear-inactive-mark)


-Phil

Re: delete-selection-mode as default

[Phil Sainty]

On 15/09/18 02:29, Phil Sainty wrote:
> The only approach I can think of is to have the mark forcibly set
> to nil whenever the region is inactive, so that commands which
> want to use the region will fail.

Ah ignore that -- as Alan points out, `mark-even-if-inactive' is
implemented and seems to solve this cleanly.

Re: delete-selection-mode as default

[Eli Zaretskii]

> From: Yuri Khan <yurivkhan@gmail.com>
> Date: Fri, 14 Sep 2018 20:41:46 +0700
> Cc: hw@adminart.net, spacibba@aol.com, 
> 	Joost Kremers <joostkremers@fastmail.fm>, Noam Postavsky <npostavs@gmail.com>, 
> 	Emacs developers <emacs-devel@gnu.org>, Eli Zaretskii <eliz@gnu.org>, Drew Adams <drew.adams@oracle.com>, 
> 	Phillip Lord <phillip.lord@russet.org.uk>
> 
> *The* core concept of Emacs as I understand it is its infinite
> customizability, and this is pretty much the main reason I stick with
> it.

There are limits to customizing Emacs.  Beyond those limits, what you
have is the basic ideas on which Emacs is based; if you want to change
them, you will have to write a different editor.

The region is one such basic idea.  If you want it to behave exactly
as selections in other editors, you are not talking about Emacs.  We
can (and do) provide approximations to what other editors do with
selections, but they are just that: approximations.

So I suggest not to ignore what Alan says, because I think there's a
hard nut of truth there, which we should endorse if we want to have a
common language.

IMO, the basic conundrum of what we have now with transient-mark-mode
and delete-selection-mode is that we are trying to cover turf that
cannot be covered by a single feature.  As result, large groups of
users will become unhappy, no matter what we do.

The region is currently used for 3 purposes: navigation, invoking
commands on a region of text, and delete-selection-mode.  (If someone
thinks that delete-selection-mode is a variant of "invoking commands
on a region of text", they are mistaken, and this long discussion is
one proof of that mistake.)  It should be clear from this discussion
that there are fundamental tensions between these 3 purposes.  The
first two can be reconciled by using the "active" vs "inactive"
region, something we already have.  This distinction is needed because
an Emacs buffer will almost always have a region, and therefore users
need some knob to control whether a command should act on the region
or on the entire buffer.  (It is possible that we need some new
command to "activate" the region, because the current method are IMO
unsatisfactory: they require navigation, which is totally gratuitous.)

The third use of the region, the one needed for delete-selection-mode,
is IMO impossible to reconcile with the other two.  Instead of trying
to reconcile them with some trick, we should consider introducing a
new "state" of the region, which will be activated by a special
command, or could be optionally activated by "C-x C-x" etc., given
some optional setting.  IOW, let the users "arm" the region for
delete-selection type of commands, similarly to how they currently
"activate" it for the other purpose.  Then the user could decide what
exactly they want the region to provide, and the basic conundrum is
gone.

> With transient-mark-mode being the Emacs default, I’m inclined to
> consider it a bug that certain commands act on the inactive region
> when t-m-m is enabled, and possibly a flaw that (interactive "r")
> makes it so easy to define such commands.

It's not a bug, it's a feature: commands that make no sense without
the region, like "upcase-region", should not need me to activate the
region for them to do what I expect them.

Other commands, which make sense both when there is and there isn't a
region, need an indication of what the user wants them to do, and
whether the region is active is that indication.

The problem is that we now want to introduce yet another, 3rd meaning
of the region, which is not identical to either of the other two.

RE: delete-selection-mode as default

[Drew Adams]

> The region is currently used for 3 purposes: navigation, invoking
> commands on a region of text, and delete-selection-mode.  (If someone
> thinks that delete-selection-mode is a variant of "invoking commands
> on a region of text", they are mistaken, and this long discussion is
> one proof of that mistake.)  It should be clear from this discussion
> that there are fundamental tensions between these 3 purposes.  The
> first two can be reconciled by using the "active" vs "inactive"
> region, something we already have.  This distinction is needed because
> an Emacs buffer will almost always have a region, and therefore users
> need some knob to control whether a command should act on the region
> or on the entire buffer.  (It is possible that we need some new
> command to "activate" the region, because the current method are IMO
> unsatisfactory: they require navigation, which is totally gratuitous.)
> 
> The third use of the region, the one needed for delete-selection-mode,
> is IMO impossible to reconcile with the other two.  Instead of trying
> to reconcile them with some trick, we should consider introducing a
> new "state" of the region, which will be activated by a special
> command, or could be optionally activated by "C-x C-x" etc., given
> some optional setting.  IOW, let the users "arm" the region for
> delete-selection type of commands, similarly to how they currently
> "activate" it for the other purpose.  Then the user could decide what
> exactly they want the region to provide, and the basic conundrum is
> gone.

`delete-selection-mode' is 5 well-defined behaviors for the active
region, carried out when you invoke a command. It's nothing
more than that.

Which of those 5 behaviors to use depends on the command you
invoke when the region is active.

Users can trivially control which of the 5 behaviors to use for
a given command, just by putting a property on the command
symbol. These are the possible property values and associated
behaviors:

1. nil: Do nothing (no-op). Same as turning off d-s-m mode
for that command.

2. non-nil and not one of the symbols below (default):
Delete (do not kill) the active region (`delete-active-region').
Then invoke the command.

3. `kill': Kill the active region (`kill-region'). Then invoke
the command.

4. `supersede': Just delete the active region. Do not invoke
the command.

5. `yank': Delete the active region, and make sure that the
text deleted is not the same as the text that gets yanked.
(Used only for a command that yanks.)

There's no difficulty "reconciling" d-s-m with the "other
uses" of the region that you cite. None whatsoever.
You've shown none, AFAICT. No trick is needed. It just
works.

A user or code can turn d-s-m off anytime. Or turn it off
for any given command (#1 above).

> Other commands, which make sense both when there is and there
> isn't a region, need an indication of what the user wants them to
> do, and whether the region is active is that indication.

Yes.

> The problem is that we now want to introduce yet another, 3rd meaning
> of the region, which is not identical to either of the other two.

There is no 3rd meaning of the region. There is not even a
2nd meaning. There is one meaning of the region - the text
delimited by point and mark.

If t-m-m is on then the region can have two states: active or
inactive. If the region is active and d-s-m is on then it can be
automatically deleted when you invoke a command. That's all.

There is nothing complicated or mysterious about d-s-m. If
there were - if there were some crazy irreconcilability, then
the same would be true of `C-w' and `delete-active-region'.

There is also nothing complicated or mysterious about t-m-m.
There is also nothing complicated about Emacs behavior
when t-m-m and d-s-m are off.

Misunderstandings come from mistaken expectations and
the fact that different users use Emacs differently.

Confusion can come from the fact that there are multiple
knobs to control region behavior (and not just two modes,
t-m-m and d-s-m), and it's not obvious sometimes that a
given knob exists or how the various knobs interact.

I do think it would help to have a command that only
activates the region. Making `C-x C-x' do double duty is
truly one place where confusion can get sown. It should
be _able_ to do double duty, for convenience. But users
should also be able to only activate the region and only
swap point and mark - as separate operations.

Re: delete-selection-mode as default

[Eli Zaretskii]

> Date: Fri, 14 Sep 2018 08:23:31 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: acm@muc.de, hw@adminart.net, spacibba@aol.com, joostkremers@fastmail.fm,
>         npostavs@gmail.com, emacs-devel@gnu.org, phillip.lord@russet.org.uk
> 
> Users can trivially control which of the 5 behaviors to use for
> a given command, just by putting a property on the command
> symbol.

Putting properties on symbols to change the behavior of a command is
not user-level customization.  IOW, we are miscommunicating.

> There's no difficulty "reconciling" d-s-m with the "other
> uses" of the region that you cite. None whatsoever.
> You've shown none, AFAICT. No trick is needed. It just
> works.

This whole thread makes it acutely clear that there is a problem.

And your message actually agrees with me towards the end.

Re: delete-selection-mode as default

[hw]

Drew Adams <drew.adams@oracle.com> writes:


> [...]
> I do think it would help to have a command that only
> activates the region. Making `C-x C-x' do double duty is
> truly one place where confusion can get sown. It should
> be _able_ to do double duty, for convenience. But users
> should also be able to only activate the region and only
> swap point and mark - as separate operations.

If you do that, please make it so that the mark can be made visible.

One idea what it could look like would be a box around the character
where it is, like the box you get where the point is when the frame is
not active.  I'd just use different colours.  Something to make it
visible ...

Why aren't we able to see it?

Re: delete-selection-mode as default

[hw]

Eli Zaretskii <eliz@gnu.org> writes:

> [...]
> The region is currently used for 3 purposes: navigation, invoking
> commands on a region of text, and delete-selection-mode.

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.

> (If someone thinks that delete-selection-mode is a variant of
> "invoking commands on a region of text", they are mistaken, and this
> long discussion is one proof of that mistake.)

That's why I said it's misguided in that it is an entirely different
idea.

> It should be clear from this discussion that there are fundamental
> tensions between these 3 purposes.  The first two can be reconciled by
> using the "active" vs "inactive" region, something we already have.
> This distinction is needed because an Emacs buffer will almost always
> have a region, and therefore users need some knob to control whether a
> command should act on the region or on the entire buffer.  (It is
> possible that we need some new command to "activate" the region,
> because the current method are IMO unsatisfactory: they require
> navigation, which is totally gratuitous.)

Just use a selection for commands to work on?  There's no need to
particularly activate a selected part of a buffer; it's kinda what a
selection is for.  A region is not needed here, either.

> The third use of the region, the one needed for delete-selection-mode,
> is IMO impossible to reconcile with the other two.

I'll leave that aside because it's an entirely different idea which may
be served with its own independent implementation.  For such an
implementation, a region is not needed.  Perhaps it could be implemented
as an optional feature of selections.

> Instead of trying to reconcile them with some trick, we should
> consider introducing a new "state" of the region,

You mean like a selection? :)  Those do not require regions.

> which will be activated by a special command,

Since a region is obsolete, we could simply use C-spc to start making a
selection and another C-spc to finish it.

> or could be optionally activated by "C-x C-x" etc., given some
> optional setting.

That is for navigation.

A region is not needed for navigation between two points.  You only need
the two points, in this case, called mark and point.  Just decouple them
from selections.

Once decoupled, there could be a command to turn the "region" that can
be imagined between mark and point into a selection.  There is no need
for a region here, either.

> IOW, let the users "arm" the region for delete-selection type of
> commands, similarly to how they currently "activate" it for the other
> purpose.  Then the user could decide what exactly they want the region
> to provide, and the basic conundrum is gone.

Users preferring d-s-m could enable the deletion option of selections.
Then if they want to delete a selection, they can make one and overwrite
it.  This doesn't need to be complicated.

>> With transient-mark-mode being the Emacs default, I’m inclined to
>> consider it a bug that certain commands act on the inactive region
>> when t-m-m is enabled, and possibly a flaw that (interactive "r")
>> makes it so easy to define such commands.
>
> It's not a bug, it's a feature: commands that make no sense without
> the region, like "upcase-region", should not need me to activate the
> region for them to do what I expect them.

What when they implicitly and secretly activate something you wanted
deactivated and do something you didn't expect?

When a selection is required for a command that does something with a
selection, the command can not work when there is no selection, and it
is a bug when it does so nonetheless, like through Emacs assuming there
was a selection when there actually is none (because Emacs lacks the
ability to distinguish if something is selected or not because its
insistence on obsolete regions gets in the way).

It's a clash between transient-mark-mode enabled and disabled.  In one
case, the behaviour is a bug because the mode suggests that commands
doing something must not do it with regions but with selections (active
regions); in the other, it's fine because there is always something for
commands that do something with something to do what they do because
there's always a region, and the second case implies that it is
generally fine for software to make mistakes of the users worse rather
than protecting them from them.

Actually, the second case is merely a slip-up, like driving your car
into the wall at full throttle and no seat belts on, either just because
you can, or unintentionally.  For some reason, only with
transient-mark-mode enabled, this becomes obvious because it has been
overlooked at least for the unintentional variant.  It probably was
never wanted even without transient-mark-mode, i. e. the intentional
variant.

Or why would I want something like upcase-region to suddenly mess up
random parts of a buffer?  A region is not a selection, it's only a
random part of the buffer that has somehow gotten between mark and
point, perhaps when mark and point were used for navigation, or when I
moved around, or when the mark happened to be set somewhere last time I
yanked something, or when the cat stepped over the keyboard while I was
pressing Ctrl or when it hit the cursor keys ...

> Other commands, which make sense both when there is and there isn't a
> region, need an indication of what the user wants them to do, and
> whether the region is active is that indication.

The indication is whether there is a selection or not.  Isn't that the
idea behind transient-mark-mode, an idea that made this mode so
successful that it became the default?

When you do not want to limit a command to a region, you do not need a
region, and the region is not needed here.

When you want to limit or to extend a command, you can use a selection
to limit or extend it to, and you don't need a region, either.

> The problem is that we now want to introduce yet another, 3rd meaning
> of the region, which is not identical to either of the other two.

The problem is the region.  It's not needed for anything and keeps
getting in the way.

RE: delete-selection-mode as default

[Drew Adams]

> 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
selection).

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
screen.

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.

HTH.

Re: delete-selection-mode as default

[hw]

Drew Adams <drew.adams@oracle.com> writes:

>> 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 -

Imagine Emacs without a region.  Mark and point still exist, only there
is no region.

> [...]
> 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.

This would be relevant for multiple selections because some of them
might not be visible in a window/on screen.  That's something you can't
do with the secondary selection.

I wasn't even aware that this might be difficult to understand because
it is so fundamental with the Emacs region that one end of it is always
visible.

> [...]
> 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
> screen.

I never thought about that before you mentioned it.  It seems quite
natural when there is only one selection because I have no desire to
scroll something off the screen I'm working with right now.


Did you ever try joe?  I haven't used it in years, but it usually comes
with the distribution, so you might be able to try it, too.  If you do,
C-k h shows help.

In joe, you make a selection by pressing C-k b to mark the beginning and
C-k k to mark the end of the selection.  The selection is called a block
in joe. It is highlighted.  You can change it any time by setting the
marks again.

Now you can copy the block with C-k c, meaning the whole block is
inserted at point, and the copy is the new selection.  The beginning and
the end of a block (selection) can both be off screen.

You can move around, and the block stays enabled and highlighted (Why
can't Emacs do that?).

When you delete the block, the block is gone and the start marker is
being remembered.  You can set a new end marker to create a new block
without setting a new start marker.

You can probably do more stuff with it, but it doesn't matter here.


So there are a few things to note:


+ start and end marker of a selection do not need to be visible

+ the selection is entirely independent from navigation

+ the selection is persistent

+ the start marker is being remembered after the selection has been used

+ I can move, type and edit normally without endangering the selection
  as if it wasn't there


And it is what I basically do with selections: I just make them when and
where I need them.  Only Emacs won't really let me do this because it
forces me to drag this dreadful useless region around all the time.  On
top of that, some functions work with the region by either being limited
to it or by being extended to it when it is highlighted while others
work with the region when it's not highlighted, and it all depends on
various modes and variables until nobody really knows anymore what it
all does under what circumstances.

Ok, Emacs is a bit more complicated than joe, but seriously?  It's not
all that different because you make a selection and then do stuff with
it.  Only Emacs makes this terrible with its inflexible and overloaded
paradigm of "the region" which can be hidden, active or both in various
ways, and is apparently important to some users even for navigation.

But it can't really get much simpler, more obvious, more efficient and
easier to use then in joe.  Joe also protects my by not having a hidden
region all the time, and I'm not going to loose the selection by
mistake.  Drew won't like it because there is no delete-selection-mode;
I like it because there is none (or maybe there is and I don't know
about it).

> 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.

The cursor is always visible in joe.  That doesn't mean that a selection
can not be persistent or that its end must always be visible.  This is
an Emacs problem because sticking to "the region" makes Emacs
inflexible.

I can imagine that this inflexibility may have been a reason for abusing
the mark for navigation: What else can you do when you have no choice
but to always stick to a fake selection ("the region") and aren't free
to move around?  Later the inflexibility brought someone to create
transient-mark-mode, and it couldn't go all the way because Emacs
remained tied up by its region.  After some more evolution, Emacs is
still being held back by its region ...


I really hope you have a chance to try out joe, it might make what I'm
trying to say much easier to understand.  I'm not saying Emacs should be
entirely the same as joe, they are too different for that --- only that
this is an example of what I'm trying to say which you can try out ---
and having it like that in Emacs in an Emacs-compatible way would be
really cool.

RE: delete-selection-mode as default

[Drew Adams]

> So there are a few things to note:
>
> + start and end marker of a selection do not need to be visible
> + the selection is entirely independent from navigation
> + the selection is persistent
> + the start marker is being remembered after the selection has been used
> + I can move, type and edit normally without endangering the selection
>   as if it wasn't there

Dunno what you mean by the 4th one. (Perhaps you mean that
you can navigate back to it?)

But all of the others, at least, are true of the secondary selection.
That's why I said that I think the sec. sel. is the closest thing
Emacs has that corresponds to the behavior you expect.

> The cursor is always visible in joe.  That doesn't mean that a selection
> can not be persistent or that its end must always be visible.  This is
> an Emacs problem because sticking to "the region" makes Emacs
> inflexible.

I meant that Emacs always has point as one end of the region,
and because (like editors typically) the cursor is always visible
on the screen, so the point end of the region is always on
screen.

There is no association between the secondary selection and
point, so the entire sec. sel. can move off screen. And it is
"persistent" in the sense I think you mean (as opposed persisting
across Emacs sessions).

Re: delete-selection-mode as default

[hw]

Drew Adams <drew.adams@oracle.com> writes:

>> So there are a few things to note:
>>
>> + start and end marker of a selection do not need to be visible
>> + the selection is entirely independent from navigation
>> + the selection is persistent
>> + the start marker is being remembered after the selection has been used
>> + I can move, type and edit normally without endangering the selection
>>   as if it wasn't there
>
> Dunno what you mean by the 4th one. (Perhaps you mean that
> you can navigate back to it?)

It means it is much like the mark in Emacs in that is being remembered,
but without dragging the region about all the time.

You can navigate with both marks.

> But all of the others, at least, are true of the secondary selection.
> That's why I said that I think the sec. sel. is the closest thing
> Emacs has that corresponds to the behavior you expect.
>
>> The cursor is always visible in joe.  That doesn't mean that a selection
>> can not be persistent or that its end must always be visible.  This is
>> an Emacs problem because sticking to "the region" makes Emacs
>> inflexible.
>
> I meant that Emacs always has point as one end of the region,
> and because (like editors typically) the cursor is always visible
> on the screen, so the point end of the region is always on
> screen.
>
> There is no association between the secondary selection and
> point, so the entire sec. sel. can move off screen. And it is
> "persistent" in the sense I think you mean (as opposed persisting
> across Emacs sessions).

Oh, I see what you mean!

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.

The secondary selection doesn't have all these problems, so it's a good
example.

Can we have a mode or something in which there is no association between
point and the end of the region?  Or can I just configure that
association away?

Re: delete-selection-mode as default

[Alan Mackenzie]

Hello, hw.

On Sun, Sep 16, 2018 at 15:48:10 +0200, hw wrote:

> Oh, I see what you mean!

> Emacs has point and (the end of) the region (selection) always entangled
> with no way to separate them or to disable the region.

You want to disable a portion of your buffer?  That doesn't make any
sense.

> That is what I dislike so much, and it causes all kinds of issues.

I do wish you could come to understand what the region is.  It would save
all sorts of problems for you.  The region is not active, never being any
sort of agent, and its existence is determined only by commands which
operate on it.  Point exists and mark exists.  When you run a command
with "-region" in its name, it operates on the buffer between point and
mark.  When you're not running such a command, the region has no
significance.  That's all.

You are attributing problems to the region which really aren't there.  A
section of your buffer is not "always entangled with no way to separate
[it]".  If you don't want to do anything to the region, don't do it.  And
if you do something to it by mistake, which won't happen often, use undo.

> The secondary selection doesn't have all these problems, so it's a good
> example.

> Can we have a mode or something in which there is no association between
> point and the end of the region?  Or can I just configure that
> association away?

Please learn what the region is.  It is just a portion of your buffer.
You cannot have point dissociated from some part of your buffer.  That
doesn't make any sense.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: delete-selection-mode as default

[hw]

Alan Mackenzie <acm@muc.de> writes:

> Hello, hw.
>
> On Sun, Sep 16, 2018 at 15:48:10 +0200, hw wrote:
>
>> Oh, I see what you mean!
>
>> Emacs has point and (the end of) the region (selection) always entangled
>> with no way to separate them or to disable the region.
>
> You want to disable a portion of your buffer?  That doesn't make any
> sense.

Portions of a buffer I don't want to do anything with do not need to be
selected, active or part of a region.

A region is not a portion of a buffer, it's a concept.  The contents of
a region reside within a buffer.  Disabling the region would disable the
concept, not its contents.

Take a picture of a tree and delete the picture.  Does that delete the
tree?  Should I take pictures of trees I don't care about only to do
nothing with them?

>> That is what I dislike so much, and it causes all kinds of issues.
>
> I do wish you could come to understand what the region is.  It would save
> all sorts of problems for you.  The region is not active,

When you have transient-mark-mode enabled, the region can be "active".
The problem with transient-mark-mode is that even when the region
should be disabled because nothing is selected and nothing is
highlighted, it remains enabled unless you set mark to nil.

> never being any sort of agent,

A region can be evaluated.  In that way, it as always an agent.

If you mean that it doesn't tend to do anything all by itself, well, it
doesn't do that, yet if the region didn't exist, it wouldn't be possible
for it to do anything in the first place, and it couldn't be evaluated.

However, I could argue that the region does something all by itself when
transient-mark-mode is enabled, the region is not active and an
operation like downcase-region happens because the region kinda
activates itself for this unless mark-even-if-inactive is nil.

So yes, it certainly has a life of its own, always.

> and its existence is determined only by commands which operate on it.

It doesn't matter which commands operate on it.  It even exists when no
commands operate on it, i. e. when it doesn't need to exist.

> Point exists and mark exists.  When you run a command
> with "-region" in its name, it operates on the buffer between point and
> mark.  When you're not running such a command, the region has no
> significance.  That's all.

The region has always significance while it exists.  It can always be
operated on.  It is a fundamental concept of Emacs.

This is important because I don't want to (accidentally) do something
with a region only because it always exists.  That's why I make a
selection.  I have transient-mark-mode enabled because I want my
selection highlighted.  That what I'm doing becomes limited to the
region is merely a side-effect, no more.

It is somewhat ironic that transient-mark-mode is required to be able to
fortify the region against accidental use with mark-even-if-inactive.

> You are attributing problems to the region which really aren't there.  A
> section of your buffer is not "always entangled with no way to separate
> [it]".  If you don't want to do anything to the region, don't do it.  And
> if you do something to it by mistake, which won't happen often, use undo.

I didn't say that a section of the buffer is entangled.  Point and mark
are entangled with making selections, with regions and with navigation.

>> The secondary selection doesn't have all these problems, so it's a good
>> example.
>
>> Can we have a mode or something in which there is no association between
>> point and the end of the region?  Or can I just configure that
>> association away?
>
> Please learn what the region is.  It is just a portion of your buffer.
> You cannot have point dissociated from some part of your buffer.  That
> doesn't make any sense.

Please try out joe.  You can see how these things work much easier
there.

Re: delete-selection-mode as default

[Yuri Khan]

On Sun, Sep 16, 2018 at 8:51 PM hw <hw@adminart.net> wrote:

> 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.
>
> Can we have a mode or something in which there is no association between
> point and the end of the region?  Or can I just configure that
> association away?

That would be hard. You’d probably want it to work for all commands,
including third-party packages. Pretty much every command that acts on
a block will assume it to be between point and mark. And a
hypothetical wordstar-like-block-mode would not know if a command
accesses point and mark as region boundaries or as a navigation stack.

A serious approach to making persistent blocks a reality would
probably involve the following:

1. Define a couple of functions, say ‘region-start’ and ‘region-end’.
Initially, make them return (min (point) (mark)) and (max (point)
(mark)), respectively.

2. Redefine (interactive "r") to use region-start and region-end.

3. Go through every function that uses (point) and (mark) to mean
region boundaries, and change them to use region-start and region-end,
too.

4. After that, make the behavior of region-start and region-end
customizable, and have wordstar-like-mode customize them to return the
appropriate marker values.

5. Do something about functions that activate the mark
(shift-selection, mark-word, mark-sexp, mark-defun, …) so that they do
the right thing to region markers.

(No, I’m not going to work on that. But someone who Really Wanted to
have a wordstar-like Emacs could try.)

RE: delete-selection-mode as default

[Drew Adams]

> > I meant that Emacs always has point as one end of the region,
> > and because (like editors typically) the cursor is always visible
> > on the screen, so the point end of the region is always on
> > screen.
> >
> > There is no association between the secondary selection and
> > point, so the entire sec. sel. can move off screen. And it is
> > "persistent" in the sense I think you mean (as opposed persisting
> > across Emacs sessions).
> 
> Oh, I see what you mean!
> 
> 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.
> 
> The secondary selection doesn't have all these problems, so it's a good
> example.
> 
> Can we have a mode or something in which there is no association between
> point and the end of the region?  Or can I just configure that association 
> away?

See Yuri's reply about this question. But no, not the region. That's
how the Emacs region is defined.

If someone wants to implement such behavior, I'd add, to what Yuri
said, that you likely do not want to change all current commands
that use the region to use such a selection that is free from point.
That likely would not make sense for some such commands.

What he describes as a possible approach for adapting the spec
(interactive "r"), for instance, might be better handled by using
a new interactive code instead.

For a different start, I'd suggest maybe starting with the secondary
selection. Much of what would be needed is already in `second-sel.el',
including being able to (1) set the sec. sel. from the Emacs region (as
one way of creating/resetting it) and (2) set the primary selection
from the secondary. And you should be able to pretty easily adapt
this to just use the primary selection, if needed.

`second-sel.el' also includes multiple selections, in this sense: it gives
you a ring of secondary selections that works like the `kill-ring'. Yes,
you meant also being able to use multiple selections _together_, at
once, which is not how the `kill-ring' and `secondary-selection-ring'
are used. They're designed for the standard use of `M-y': retrieving
a past selection.

Though using multiple selections together is not in `second-sel.el',
it too should be easy to realize (and the same thing applies to using
multiple entries of the `kill-ring' together).

You would still want to also implement easily defining multiple
selections in the way you describe for MS Windows. In Emacs
the thing to be aware of in this context is the use of `C-M-w M-w'
to append the selected text to the previous kill, instead of
creating a new kill (i.e., a new `kill-ring' entry). There is currently
nothing in `second-sel.el' that provides similar behavior for
`secondary-selection-ring', but that could easily be added.

Also, together with `second-sel.el', library `browse-kill-ring+.el',
which extends library `browse-kill-ring.el', lets you use `M-y' at
the top level to browse either the  `secondary-selection-ring' or
the ` kill-ring', or both, to choose a selection to yank. And `M-y'
following a yank from either of these rings replaces that yank
with the next (or the prefix-argth) ring entry.  IOW, it does a
`yank-pop' or a `yank-pop-secondary', as appropriate.

Actually, `browse-kill-ring+.el' allows for any number of such
rings of selections. And they could be adapted for use as
sources for commands that use multiple selections together.

Re: delete-selection-mode as default

[Eli Zaretskii]

> From: hw <hw@adminart.net>
> Date: Sun, 16 Sep 2018 15:48:10 +0200
> Cc: spacibba@aol.com, joostkremers@fastmail.fm, npostavs@gmail.com,
> 	emacs-devel@gnu.org, Yuri Khan <yurivkhan@gmail.com>, acm@muc.de,
> 	Eli Zaretskii <eliz@gnu.org>, phillip.lord@russet.org.uk
> 
> 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?

> The secondary selection doesn't have all these problems, so it's a good
> example.

The secondary selection can only be defined by mouse gestures.  And it
is not supported by any commands except those which interact with X
selections.

Re: delete-selection-mode as default

[Yuri Khan]

On Mon, Sep 17, 2018 at 12:00 AM Eli Zaretskii <eliz@gnu.org> wrote:

> 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?

The point of persistent blocks is that you can mark a region and leave
it for a while before actually doing something to it. It is not a goal
to be able to mark a block somewhere far away without ever leaving
your position.

So: you move point to one end, press a key (or hold down Shift), move
to the other end, press another key (or release Shift), move to the
target position, press an action key (C-k c for copy, C-k v for move).
All without killing anything. Very pacifistic.

Re: delete-selection-mode as default

[Eli Zaretskii]

> From: Yuri Khan <yurivkhan@gmail.com>
> Date: Mon, 17 Sep 2018 01:20:19 +0700
> Cc: hw@adminart.net, Drew Adams <drew.adams@oracle.com>, spacibba@aol.com, 
> 	Joost Kremers <joostkremers@fastmail.fm>, Noam Postavsky <npostavs@gmail.com>, 
> 	Emacs developers <emacs-devel@gnu.org>, Alan Mackenzie <acm@muc.de>, 
> 	Phillip Lord <phillip.lord@russet.org.uk>
> 
> The point of persistent blocks is that you can mark a region and leave
> it for a while before actually doing something to it. It is not a goal
> to be able to mark a block somewhere far away without ever leaving
> your position.
> 
> So: you move point to one end, press a key (or hold down Shift), move
> to the other end, press another key (or release Shift), move to the
> target position, press an action key (C-k c for copy, C-k v for move).
> All without killing anything. Very pacifistic.

And how, may I ask, you then indicate which of the "blocks" is to be
acted upon by some command?

More to the point, what does this feature have to do with
delete-selection-mode and transient-mark-mode, and the issues we have
with their mix?  Or did this discussion wandered away without hope?

RE: delete-selection-mode as default

[Drew Adams]

> > 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?
> 
> The point of persistent blocks is that you can mark a region and leave
> it for a while before actually doing something to it. It is not a goal
> to be able to mark a block somewhere far away without ever leaving
> your position.
> 
> So: you move point to one end, press a key (or hold down Shift), move
> to the other end, press another key (or release Shift), move to the
> target position, press an action key (C-k c for copy, C-k v for move).
> All without killing anything. Very pacifistic.

Yes.

And that's the kind of behavior we have for the secondary
selection. And how you set it interactively (or even by
program) is not important to its behavior in this regard.

Re: delete-selection-mode as default

[hw]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: hw <hw@adminart.net>
>> Date: Sun, 16 Sep 2018 15:48:10 +0200
>> Cc: spacibba@aol.com, joostkremers@fastmail.fm, npostavs@gmail.com,
>> 	emacs-devel@gnu.org, Yuri Khan <yurivkhan@gmail.com>, acm@muc.de,
>> 	Eli Zaretskii <eliz@gnu.org>, phillip.lord@russet.org.uk
>> 
>> 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.

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.

To be able to go to the other end of the selection, you first have to
make one.  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 --- unless
operations supposed to do something with the selection don't do that
because they start working from where point is rather than from where
the start of the selection is.  Such operations may need to be fixed.

> [...]

Re: delete-selection-mode as default

[Eli Zaretskii]

> From: hw <hw@adminart.net>
> Cc: spacibba@aol.com,  joostkremers@fastmail.fm,  npostavs@gmail.com,  emacs-devel@gnu.org,  yurivkhan@gmail.com,  acm@muc.de,  drew.adams@oracle.com,  phillip.lord@russet.org.uk
> 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.

Re: delete-selection-mode as default

[hw]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: hw <hw@adminart.net>
>> Cc: spacibba@aol.com, joostkremers@fastmail.fm, npostavs@gmail.com,
>> emacs-devel@gnu.org, yurivkhan@gmail.com, acm@muc.de,
>> drew.adams@oracle.com, phillip.lord@russet.org.uk
>> 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.

It refers to your idea that it would be inconvenient having to use a
pointing device to do something with a selection.

>> 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?

If you were referring to a persistent selection, the difference would be
that the persistent selection has two markers rather than only one.
Still you do not need to use a pointing device.

>> 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.

You could even use a pointing device to select something.

>> 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.

How do you go to the other end of a selection before it has been made,
and why would you?

Re: delete-selection-mode as default

[Eli Zaretskii]

> From: hw <hw@adminart.net>
> Cc: spacibba@aol.com,  joostkremers@fastmail.fm,  npostavs@gmail.com,  emacs-devel@gnu.org,  yurivkhan@gmail.com,  acm@muc.de,  drew.adams@oracle.com,  phillip.lord@russet.org.uk
> Date: Wed, 19 Sep 2018 01:45:59 +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.
> 
> It refers to your idea that it would be inconvenient having to use a
> pointing device to do something with a selection.

In that case, the issue is still there, because the selection had to
be created somehow, and that would be possible by mouse only.  So the
Emacs way is more convenient in many use cases.

> You could even use a pointing device to select something.

Of course.  But it's a distraction to use a pointing device while
typing.

> >> 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.
> 
> How do you go to the other end of a selection before it has been made,

With cursor motion commands, of which Emacs has a lot, for the various
meaningful portions of text (word, sentence, paragraph, sexp, etc.).

> and why would you?

To define the region as appropriate for the command I want to invoke.

Re: delete-selection-mode as default

[hw]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: hw <hw@adminart.net>
>> Cc: spacibba@aol.com, joostkremers@fastmail.fm, npostavs@gmail.com,
>> emacs-devel@gnu.org, yurivkhan@gmail.com, acm@muc.de,
>> drew.adams@oracle.com, phillip.lord@russet.org.uk
>> Date: Wed, 19 Sep 2018 01:45:59 +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.
>> 
>> It refers to your idea that it would be inconvenient having to use a
>> pointing device to do something with a selection.
>
> In that case, the issue is still there, because the selection had to
> be created somehow, and that would be possible by mouse only.  So the
> Emacs way is more convenient in many use cases.

You do not need to use the trackball when you want to make a selection
in joe.  Why would it be required in Emacs?

>> You could even use a pointing device to select something.
>
> Of course.  But it's a distraction to use a pointing device while
> typing.

right

>> >> 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.
>> 
>> How do you go to the other end of a selection before it has been made,
>
> With cursor motion commands, of which Emacs has a lot, for the various
> meaningful portions of text (word, sentence, paragraph, sexp, etc.).

How can these meaningful portions of text be at the end of a selection
that hasn't been made yet?

>> and why would you?
>
> To define the region as appropriate for the command I want to invoke.

So you go somewhere first and make a selection before you can go to
either end of it.

RE: delete-selection-mode as default

[Drew Adams]

> > The secondary selection doesn't have all these problems, 
> > so it's a good example.
> 
> The secondary selection can only be defined by mouse gestures. 

In vanilla Emacs, yes. But not if you use `second-sel.el'.

You can define (set) it in several ways using the keyboard (suggested keys shown):

* Start secondary with `C-x C-M-SPC' (`set-secondary-start').
* End secondary with `C-x C-M-<return>' (`secondary-save-then-kill').
* Set secondary to the region by using a prefix arg with `C-M-y' 
(`secondary-yank|select|move|swap')

The last of these does multiple things, depending on the prefix arg:

* None: Yank secondary selection
* Zero: Select secondary as region. I.e., put region where secondary is.
* > 0:  Move secondary to region.
* < 0:  Swap region and secondary.

The last two of these are ways to set the secondary from the region.

So just as you can set the region in multiple ways, so can you set the secondary. Each way of setting the region gives you a way to set the secondary.

Re: delete-selection-mode as default

[Eli Zaretskii]

> Date: Sun, 16 Sep 2018 11:04:50 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: spacibba@aol.com, joostkremers@fastmail.fm, npostavs@gmail.com,
>         emacs-devel@gnu.org, yurivkhan@gmail.com, acm@muc.de,
>         drew.adams@oracle.com, phillip.lord@russet.org.uk
> 
> > > The secondary selection doesn't have all these problems, 
> > > so it's a good example.
> > 
> > The secondary selection can only be defined by mouse gestures. 
> 
> In vanilla Emacs, yes. But not if you use `second-sel.el'.
> 
> You can define (set) it in several ways using the keyboard (suggested keys shown):
> 
> * Start secondary with `C-x C-M-SPC' (`set-secondary-start').
> * End secondary with `C-x C-M-<return>' (`secondary-save-then-kill').

Which ends the secondary at point position, something that was the
main point of this discussion.

Can you envision a way of setting a selection without the mouse,
except when point is at one of the two ends of the selection?

RE: delete-selection-mode as default

[Drew Adams]

> > > > The secondary selection doesn't have all these problems,
> > > > so it's a good example.
> > >
> > > The secondary selection can only be defined by mouse gestures.
> >
> > In vanilla Emacs, yes. But not if you use `second-sel.el'.
> >
> > You can define (set) it in several ways using the keyboard (suggested keys
> shown):
> >
> > * Start secondary with `C-x C-M-SPC' (`set-secondary-start').
> > * End secondary with `C-x C-M-<return>' (`secondary-save-then-kill').
> 
> Which ends the secondary at point position, something that was the
> main point of this discussion.

That's not the point you made, of the secondary only being
defined by mouse gestures. My reply is to that point.

> Can you envision a way of setting a selection without the mouse,
> except when point is at one of the two ends of the selection?

Of course I can. It can easily be set between any two positions.
Neither end need have any relation to point.

(And even in asking that you switched from "mouse gestures" to
"selection".)

(defun my-set-secondary (beg end)
  "Set the secondary selection to start at BEG and end at END."
  (setq mouse-secondary-start  (make-marker))
  (move-marker mouse-secondary-start beg)
  (move-overlay mouse-secondary-overlay beg end))

RE: delete-selection-mode as default

[Drew Adams]

> > The point of persistent blocks is that you can mark a region and leave
> > it for a while before actually doing something to it. It is not a goal
> > to be able to mark a block somewhere far away without ever leaving
> > your position.
> >
> > So: you move point to one end, press a key (or hold down Shift), move
> > to the other end, press another key (or release Shift), move to the
> > target position, press an action key (C-k c for copy, C-k v for move).
> > All without killing anything. Very pacifistic.
> 
> And how, may I ask, you then indicate which of the "blocks" is to be
> acted upon by some command?

How do you choose anything in Emacs? There are many ways.

To choose a kill (or to a secondary selection) using
`browse-kill-ring', you cycle among those on the ring
to get to the one you want.

That's also an approach for choosing a previous search
pattern for Isearch.

But another common approach lets you use completion to
choose. That's used even for selections (and buffer positions
for navigation) by several libraries.

Still another approach is to offer a menu of choices.

(But I wonder why you even ask such a question.)

> More to the point, what does this feature have to do with
> delete-selection-mode and transient-mark-mode, and the issues we have
> with their mix?  Or did this discussion wandered away without hope?

There are at least two threads (per their Subject lines) that
have been discussing point, mark, region, selection, navigation,
etc. in Emacs. Hw has put his preferences front and center in
the discussions, and they have to do with the kind of thing
discussed right here: defining and using stretches of text that
do not necessarily have the cursor at one end.

I too would like to see a narrower discussion that fits only
the current Subject line. I would like to see that in addition
the more far-ranging discussion, which I also welcome. But
this Subject's actual thread, like the one it forked from, has
been pretty wide-ranging throughout.

Re: delete-selection-mode as default

[Yuri Khan]

On Mon, Sep 17, 2018 at 3:29 AM Drew Adams <drew.adams@oracle.com> wrote:

> > > The point of persistent blocks is that you can mark a region and leave
> > > it for a while before actually doing something to it. It is not a goal
> > > to be able to mark a block somewhere far away without ever leaving
> > > your position.
> >
> > And how, may I ask, you then indicate which of the "blocks" is to be
> > acted upon by some command?
>
> How do you choose anything in Emacs? There are many ways. […]
>
> (But I wonder why you even ask such a question.)

No, it is a valid question, and possibly one of the reasons why
persistent blocks went out of fashion. As I understand it, the pure
persistent block model started out in single-buffer, single-window
editors. In that setup, there is never more than one block.

As soon as you have buffers and windows, the “which one?” question
arises, and there are two major ways to answer it.

* You can say the block is global; if you select a block in buffer B,
then the block in buffer A is unselected. But this works against the
general idea of block persistence.

* Or you can say every buffer or window can have a block. Then you can
have an easy gesture for copying/moving/deleting the block in the
current buffer/window, but no natural way of direct inter-buffer or
inter-window copying/moving. (Asking the user a question equivalent to
“please type the first few characters of the selected region you’d
like to copy and press TAB or, at your leisure, make your way through
the 123 blocks currently active, one M-n at a time” is probably not
the answer.)

Several editors that had persistent blocks and multiple buffers
arrived at the mixed model: persistent buffer-local blocks +
clipboard. You can copy and move blocks within the current buffer
directly, but if you want to copy or move across buffers, you go to
the source buffer, copy or cut to clipboard, then go to the target
buffer and paste. Of course you can also do that in a single buffer.
So you now have two ways of doing the same things, and the less
versatile one falls into disuse. You now use the clipboard for most
copy and move operations.

Now there is a subtle shift in your workflow. Before, you could mark a
block, go to the target position, and press C-k v to move the block
here. Now, when you cut, point is moved to where you cut from, because
otherwise you could accidentally cut something and not notice it. So
you cut right after selecting, and now persistent blocks lose most of
the appeal.

Re: delete-selection-mode as default

[Yuri Khan]

On Sun, Sep 16, 2018 at 10:15 AM hw <hw@adminart.net> wrote:

> In joe, you make a selection by pressing C-k b to mark the beginning and
> C-k k to mark the end of the selection.  The selection is called a block
> in joe. It is highlighted.  You can change it any time by setting the
> marks again.
>
> Now you can copy the block with C-k c, meaning the whole block is
> inserted at point, and the copy is the new selection.  The beginning and
> the end of a block (selection) can both be off screen.

I recognize this as the WordStar block/region/selection model. Yes, I,
too, was quite used to it in my Turbo Pascal years (late ’90s). Later,
I migrated to Windows and got used to its CUA-like model.

(Emacs has a WordStar emulation in obsolete/ws-mode.el, but it is
unusable because of several reasons:

* It is unmaintained and obsolete.
* It is a major mode, meaning no syntax highlight, no
language-specific features, just text editing.
* It does not highlight the block.
* When deleting the block, it does not move point to where it was.
This makes it possible to mark a block, scroll it off the screen, and
delete it without realizing you did it.)


I think it is instructive to compare a few selection/region/block
models, all of which have been quite successful.

* WordStar model: Block is delimited by two markers, and is
highlighted. (Some implementations allow toggling the highlight; when
highlight is off, markers are preserved but block commands are not
available.) Moving the cursor or typing text does not affect block
markers (except to adjust their positions to accommodate length
changes). Basic block operations are: copy to point, move to point,
delete, write to file, read from file. (The latter inserts the
contents of the file at point and puts block markers around it.)

* Brief model: Block is delimited by mark and point (like in Emacs).
Pressing Alt+A starts selecting the corresponding type of block (which
is highlighted); pressing the same key again removes the highlight.
When selecting, newly typed text is inserted normally at point. Block
operations are: cut, copy, paste, delete, write to file. When no block
is highlighted, these act on the current line.

* Windows model: Selection is defined by two positions, one of which
is at point. Unshifted cursor movement cancels the selection, shifted
cursor movement extends or shrinks it, text insertion replaces the
selected text, and both Backspace and Delete delete the selected text.
Selection operations are cut, copy, paste, and delete; when there is
no selection, cut and copy are disabled, and Backspace and Delete act
on one character backward and forward, respectively.

Re: delete-selection-mode as default

[hw]

Yuri Khan <yurivkhan@gmail.com> writes:

> On Sun, Sep 16, 2018 at 10:15 AM hw <hw@adminart.net> wrote:
>
>> In joe, you make a selection by pressing C-k b to mark the beginning and
>> C-k k to mark the end of the selection.  The selection is called a block
>> in joe. It is highlighted.  You can change it any time by setting the
>> marks again.
>>
>> Now you can copy the block with C-k c, meaning the whole block is
>> inserted at point, and the copy is the new selection.  The beginning and
>> the end of a block (selection) can both be off screen.
>
> I recognize this as the WordStar block/region/selection model. Yes, I,
> too, was quite used to it in my Turbo Pascal years (late ’90s). Later,
> I migrated to Windows and got used to its CUA-like model.

Yes, joe is "wordstarlike".  You can start it with different names to
get different key bindings, though, like jmacs is like Emacs.

> [...]
> I think it is instructive to compare a few selection/region/block
> models, all of which have been quite successful.


,---- [ joe ]
|    New ways of selecting regions
|        The  classic  way  is to hit ^K B at the beginning and ^K K at the
|        end. These set pointers called markb and markk. Once these are set
|        you can jump to markb with Esc B and jump to markk with Esc K.
| 
|        New  way:  hit Ctrl-Right Arrow to start selecting rightward. Each
`----


The new ways refer to keys that don't work in a terminal unless you
manage to somehow configure them.  With mouse support, you use the mouse
to select.

There seems to be more to it because it seems that both pointers can be
remembered, and operations on a block are not possible when there is no
block highlighted. --- This also allows moving blocks, something that
Emacs can't do.

Also noteworthy:

,----
|    How do I deselect a highlighted region?
|        After  you  are finished with some region operations, you can just
|        leave the highlighting on if you don´t mind it (but don´t acciden‐
|        tally  hit ^K Y). If it really bothers you, however, just hit ^K B
|        ^K K, to turn the highlighting off.
| 
|        Beginning with JOE 4.2, you can hit ^C to cancel the region selec‐
|        tion.
`----


> * WordStar model: Block is delimited by two markers, and is
> highlighted. (Some implementations allow toggling the highlight; when
> highlight is off, markers are preserved but block commands are not
> available.) Moving the cursor or typing text does not affect block
> markers (except to adjust their positions to accommodate length
> changes). Basic block operations are: copy to point, move to point,
> delete, write to file, read from file. (The latter inserts the
> contents of the file at point and puts block markers around it.)

+ move block

I like that.

> * Brief model: Block is delimited by mark and point (like in Emacs).
> Pressing Alt+A starts selecting the corresponding type of block (which
> is highlighted); pressing the same key again removes the highlight.
> When selecting, newly typed text is inserted normally at point. Block
> operations are: cut, copy, paste, delete, write to file. When no block
> is highlighted, these act on the current line.
>
> * Windows model: Selection is defined by two positions, one of which
> is at point. Unshifted cursor movement cancels the selection, shifted
> cursor movement extends or shrinks it, text insertion replaces the
> selected text, and both Backspace and Delete delete the selected text.
> Selection operations are cut, copy, paste, and delete; when there is
> no selection, cut and copy are disabled, and Backspace and Delete act
> on one character backward and forward, respectively.

There are also multiple selections which you can usually make by holding
control and clicking on something with the trackball to include it into
a selection.  I'm not sure if there is a version of that which works
with text.  The wordstar model could work with multiple selections.

Re: delete-selection-mode as default

[Eli Zaretskii]

> From: hw <hw@adminart.net>
> Cc: Yuri Khan <yurivkhan@gmail.com>,  spacibba@aol.com,  joostkremers@fastmail.fm,  npostavs@gmail.com,  emacs-devel@gnu.org,  acm@muc.de,  drew.adams@oracle.com,  phillip.lord@russet.org.uk
> Date: Sun, 16 Sep 2018 00:37:43 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > [...]
> > The region is currently used for 3 purposes: navigation, invoking
> > commands on a region of text, and delete-selection-mode.
> 
> 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.

You forget the kill-ring and the kill/yank commands.  Those are almost
exactly identical to what other apps give you with copy/paste, and the
latter use selections.  So the reasons Emacs implements selections
using the region are more fundamental than just navigation.

> > (If someone thinks that delete-selection-mode is a variant of
> > "invoking commands on a region of text", they are mistaken, and this
> > long discussion is one proof of that mistake.)
> 
> That's why I said it's misguided in that it is an entirely different
> idea.

It's a very similar idea, see below.

> > It should be clear from this discussion that there are fundamental
> > tensions between these 3 purposes.  The first two can be reconciled by
> > using the "active" vs "inactive" region, something we already have.
> > This distinction is needed because an Emacs buffer will almost always
> > have a region, and therefore users need some knob to control whether a
> > command should act on the region or on the entire buffer.  (It is
> > possible that we need some new command to "activate" the region,
> > because the current method are IMO unsatisfactory: they require
> > navigation, which is totally gratuitous.)
> 
> Just use a selection for commands to work on?  There's no need to
> particularly activate a selected part of a buffer; it's kinda what a
> selection is for.  A region is not needed here, either.

Once again: in Emacs, selection _is_ the region, and for some very
good reasons.

You can, of course, start inventing an Emacs that is based on
selections.  But if that Emacs will still support copy/paste inside
Emacs and vis-a-vis other apps, if it will support commands that
operate on the selected text and/or work different when some text is
selected -- then what you will have at the end is the same Emacs, just
one where the region is called "selection".  OK, maybe you will lose
the ability to do "C-x C-x" for navigation -- but to what purpose?

It should be possible to introduce a separate feature of "selection",
similar to what we already do with secondary-selection.  But if you
want commands and features to be sensitive to such a selection, you
will have to write a lot of code and change a lot of commands.  You
are, of course, welcome to work on that, but my idea was to try a much
simpler solution, one that doesn't need any significant changes in the
infrastructure or the implementation of the relevant commands.

If you do NOT entertain the possibility of introducing such a new kind
of "selections", then it is IMO best to remember that in Emacs
"selection" and 'region" are synonyms.  By using these terms as if
they were 2 different features you are just confusing this discussion.

> > Instead of trying to reconcile them with some trick, we should
> > consider introducing a new "state" of the region,
> 
> You mean like a selection? :)  Those do not require regions.

Region and selection is the same thing in Emacs.

> Since a region is obsolete, we could simply use C-spc to start making a
> selection and another C-spc to finish it.

How is that different from typing C-SPC to start a region? it isn't.

> > or could be optionally activated by "C-x C-x" etc., given some
> > optional setting.
> 
> That is for navigation.

No, it's also for "activating" the region (a.k.a. "selection"), which
causes some commands to "sense" the selected text.

> A region is not needed for navigation between two points.  You only need
> the two points, in this case, called mark and point.  Just decouple them
> from selections.

You can't: selection in Emacs is the region.

> Users preferring d-s-m could enable the deletion option of selections.
> Then if they want to delete a selection, they can make one and overwrite
> it.  This doesn't need to be complicated.

You are missing the point.  The point is that sometimes the user
doesn't want a selection to be replaced by a character she types, and
other times she does.  The issue at hand is how to design a UI that
will allow both possibilities, without telling the users to turn on or
off delete-selection-mode for that purpose.

> >> With transient-mark-mode being the Emacs default, I’m inclined to
> >> consider it a bug that certain commands act on the inactive region
> >> when t-m-m is enabled, and possibly a flaw that (interactive "r")
> >> makes it so easy to define such commands.
> >
> > It's not a bug, it's a feature: commands that make no sense without
> > the region, like "upcase-region", should not need me to activate the
> > region for them to do what I expect them.
> 
> What when they implicitly and secretly activate something you wanted
> deactivated and do something you didn't expect?

"Parse error".  Sorry, I don't understand what you meant here.

> When a selection is required for a command that does something with a
> selection, the command can not work when there is no selection, and it
> is a bug when it does so nonetheless, like through Emacs assuming there
> was a selection when there actually is none (because Emacs lacks the
> ability to distinguish if something is selected or not because its
> insistence on obsolete regions gets in the way).

This flies in the face of a long tradition in Emacs to provide DWIMish
operation, whereby if something makes a lot of sense in some
specialized situation, Emacs should do that automatically, even if it
deviates from the "normal" operation.  A notable example is what C-t
does when point is at end of line.

So if some effect of a command would make sense when it is invoked
without any "selection", we program Emacs to do that, and that is not
a bug at all, it's why Emacs shines in many situations where other
editors don't.

> It's a clash between transient-mark-mode enabled and disabled.  In one
> case, the behaviour is a bug because the mode suggests that commands
> doing something must not do it with regions but with selections (active
> regions); in the other, it's fine because there is always something for
> commands that do something with something to do what they do because
> there's always a region, and the second case implies that it is
> generally fine for software to make mistakes of the users worse rather
> than protecting them from them.
> 
> Actually, the second case is merely a slip-up, like driving your car
> into the wall at full throttle and no seat belts on, either just because
> you can, or unintentionally.  For some reason, only with
> transient-mark-mode enabled, this becomes obvious because it has been
> overlooked at least for the unintentional variant.  It probably was
> never wanted even without transient-mark-mode, i. e. the intentional
> variant.

"Parse error".  "One case"? "second case"?  What is this about?

> Or why would I want something like upcase-region to suddenly mess up
> random parts of a buffer?

Only they aren't random.

> A region is not a selection, it's only a random part of the buffer
> that has somehow gotten between mark and point, perhaps when mark
> and point were used for navigation, or when I moved around, or when
> the mark happened to be set somewhere last time I yanked something,
> or when the cat stepped over the keyboard while I was pressing Ctrl
> or when it hit the cursor keys ...

The region _is_ selection in Emacs.  If you want Emacs to do something
with text in the region, you will redefine the region before invoking
the command -- unless you know the region is already set up as you
want it, e.g. because you have just yanked the text to which you want
to apply the command.  This is exactly why region and its integration
with commands in Emacs is a very valuable feature.

> > Other commands, which make sense both when there is and there isn't a
> > region, need an indication of what the user wants them to do, and
> > whether the region is active is that indication.
> 
> The indication is whether there is a selection or not.

Same thing.

> The problem is the region.  It's not needed for anything and keeps
> getting in the way.

Not in Emacs, it isn't.

Re: delete-selection-mode as default

[hw]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: hw <hw@adminart.net>
>> Cc: Yuri Khan <yurivkhan@gmail.com>, spacibba@aol.com,
>> joostkremers@fastmail.fm, npostavs@gmail.com, emacs-devel@gnu.org,
>> acm@muc.de, drew.adams@oracle.com, phillip.lord@russet.org.uk
>> Date: Sun, 16 Sep 2018 00:37:43 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > [...]
>> > The region is currently used for 3 purposes: navigation, invoking
>> > commands on a region of text, and delete-selection-mode.
>> 
>> 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.
>
> You forget the kill-ring and the kill/yank commands.  Those are almost
> exactly identical to what other apps give you with copy/paste, and the
> latter use selections.  So the reasons Emacs implements selections
> using the region are more fundamental than just navigation.

What are these fundamental reasons?  Other programs, like joe, allow you
to use the selection for navigation without having a region.

>> > (If someone thinks that delete-selection-mode is a variant of
>> > "invoking commands on a region of text", they are mistaken, and this
>> > long discussion is one proof of that mistake.)
>> 
>> That's why I said it's misguided in that it is an entirely different
>> idea.
>
> It's a very similar idea, see below.
>
>> > It should be clear from this discussion that there are fundamental
>> > tensions between these 3 purposes.  The first two can be reconciled by
>> > using the "active" vs "inactive" region, something we already have.
>> > This distinction is needed because an Emacs buffer will almost always
>> > have a region, and therefore users need some knob to control whether a
>> > command should act on the region or on the entire buffer.  (It is
>> > possible that we need some new command to "activate" the region,
>> > because the current method are IMO unsatisfactory: they require
>> > navigation, which is totally gratuitous.)
>> 
>> Just use a selection for commands to work on?  There's no need to
>> particularly activate a selected part of a buffer; it's kinda what a
>> selection is for.  A region is not needed here, either.
>
> Once again: in Emacs, selection _is_ the region, and for some very
> good reasons.

Not to me.  The selection is what becomes highlighted when I make one.

> You can, of course, start inventing an Emacs that is based on
> selections.  But if that Emacs will still support copy/paste inside
> Emacs and vis-a-vis other apps, if it will support commands that
> operate on the selected text and/or work different when some text is
> selected -- then what you will have at the end is the same Emacs, just
> one where the region is called "selection".  OK, maybe you will lose
> the ability to do "C-x C-x" for navigation -- but to what purpose?

I never use that, why would I?

> It should be possible to introduce a separate feature of "selection",
> similar to what we already do with secondary-selection.  But if you
> want commands and features to be sensitive to such a selection, you
> will have to write a lot of code and change a lot of commands.  You
> are, of course, welcome to work on that, but my idea was to try a much
> simpler solution, one that doesn't need any significant changes in the
> infrastructure or the implementation of the relevant commands.

Do you mean the one that solves some problems with delete-selection-mode
by "arming" the region instead of activating it?  I'd rather call it
"disarming" because disarming before killing makes more sense than
arming before killing :)

IIUC, your idea is to *generally* either "activate" a region or to
"disarm" it, depending on which behaviour a user wants.  I'm not sure
how this is different from delete-selection-mode, and I think it needs
more variations:

By setting mark-even-if-inactive to nil, I have "fortified" the region
because nothing can be done with it unless it is "active".

There are more variations, like disabling shift-selection and disabling
making a selection with the trackball.  That might make the region
"protected".  When it's also fortified, it would be "inert", unless it
has been disarmed, in which case it would be "content".

We'd have to find more funny names to designate all possible
combinations of the fundamental variations.  That would be the chance to
throw out "active" and to replace it with "limiting".  Then we could
also have "highlightable", but that kinda throws out the concept of "the
region" because we do not want the region to be highlighted all the
time.  Perhaps it could still be highlighted from starting to make the
selection until something has been done with it when "highlightable" is
desired.

I would also want "marked", meaning that the mark is displayed.

I like the idea because having a domain of fundamental region states
that can be combined with each other can lead to more consistency, and
the whole domain could be explained to users so they can get the
behaviour they prefer by picking any combination of states.  Currently,
all the modes and options involved appear to be unrelated, and users may
never find what suits them best because they don't know all the
available options.  Bringing them together in one domain would change
that.

> If you do NOT entertain the possibility of introducing such a new kind
> of "selections", then it is IMO best to remember that in Emacs
> "selection" and 'region" are synonyms.  By using these terms as if
> they were 2 different features you are just confusing this discussion.

They actually *are* two different things for me.  The selection is what
I make to work with and what becomes highlighted.  The region is
something unwanted always lurking in the background waiting for me to
make a mistake and making me feel uneasy.

The problem is that Emacs is unable to make this important distinction.
I could say that this confuses things.

However, with mark-even-if-inactive set to nil, this lurking daemon has
kinda been banished because it can only lurk and not do anything.

>> > Instead of trying to reconcile them with some trick, we should
>> > consider introducing a new "state" of the region,
>> 
>> You mean like a selection? :)  Those do not require regions.
>
> Region and selection is the same thing in Emacs.

That's the problem ...

>> Since a region is obsolete, we could simply use C-spc to start making a
>> selection and another C-spc to finish it.
>
> How is that different from typing C-SPC to start a region? it isn't.

It is different because the end of the region is also being marked and
becomes independent from point.  Using the same key binding is only
intended to make it easy.

>> > or could be optionally activated by "C-x C-x" etc., given some
>> > optional setting.
>> 
>> That is for navigation.
>
> No, it's also for "activating" the region (a.k.a. "selection"), which
> causes some commands to "sense" the selected text.

Navigating a buffer and making selections are two totally unrelated
things.  It doesn't make sense that the region be "navigating"
(especially when it is not "active").

I might understand limiting navigation to the active region when
transient-mark-mode is enabled --- but this doesn't come up because
unfortunately, point can not be disentangled from the region.

Besides, if a region was large enough that I would want to navigate it,
I probably wouldn't want it highlighted.  That would require "fortified"
to be independent of "highlightable", which is currently not possible.

>> A region is not needed for navigation between two points.  You only need
>> the two points, in this case, called mark and point.  Just decouple them
>> from selections.
>
> You can't: selection in Emacs is the region.

That's the problem ...

>> Users preferring d-s-m could enable the deletion option of selections.
>> Then if they want to delete a selection, they can make one and overwrite
>> it.  This doesn't need to be complicated.
>
> You are missing the point.  The point is that sometimes the user
> doesn't want a selection to be replaced by a character she types, and
> other times she does.  The issue at hand is how to design a UI that
> will allow both possibilities, without telling the users to turn on or
> off delete-selection-mode for that purpose.

Do you mean there is a big problem with delete-selection-mode when
transient-mark-mode is disabled because then there is "maybe sometimes"
a selection a user may want to replace by inserting characters?

This problem wouldn't exist if the region could be disentangled from
making selections.  I'm not sure if it does exist because nobody would
use d-s-m without t-m-m unless they wanted to do something that doesn't
make sense.

Other than that, Emacs would have to read the users` minds to figure out
what they want with each character they insert.

>> >> With transient-mark-mode being the Emacs default, I’m inclined to
>> >> consider it a bug that certain commands act on the inactive region
>> >> when t-m-m is enabled, and possibly a flaw that (interactive "r")
>> >> makes it so easy to define such commands.
>> >
>> > It's not a bug, it's a feature: commands that make no sense without
>> > the region, like "upcase-region", should not need me to activate the
>> > region for them to do what I expect them.
>> 
>> What when they implicitly and secretly activate something you wanted
>> deactivated and do something you didn't expect?
>
> "Parse error".  Sorry, I don't understand what you meant here.

Upcase-region works without activating the region first though
transient-mark-mode says that commands should be limited to the "active"
region.  So for upcase-region to work when no region is "active", it is
as if the region is secretly activated so that upcase-region can work,
and this may be unexpected.

>> When a selection is required for a command that does something with a
>> selection, the command can not work when there is no selection, and it
>> is a bug when it does so nonetheless, like through Emacs assuming there
>> was a selection when there actually is none (because Emacs lacks the
>> ability to distinguish if something is selected or not because its
>> insistence on obsolete regions gets in the way).
>
> This flies in the face of a long tradition in Emacs to provide DWIMish
> operation, whereby if something makes a lot of sense in some
> specialized situation, Emacs should do that automatically, even if it
> deviates from the "normal" operation.  A notable example is what C-t
> does when point is at end of line.
>
> So if some effect of a command would make sense when it is invoked
> without any "selection", we program Emacs to do that, and that is not
> a bug at all, it's why Emacs shines in many situations where other
> editors don't.

That's a difficult thing because it creates inconsistencies.  In this
case, one problem is that the region is changing all the time through
inserting characters (or files) and through navigation.  That is
actually always the problem, plus you can't even see the region and not
even the mark.

So MOTT, you have a region (which you call selection) that is entirely
random, unlike a selection which has explicitly been made to contain
what it is supposed to contain.  You really can't call the region a
selection.  Nothing in particular has been selected, and things merely
happen to have ended up the way they did and, because of technical
limitations, a region is randomly formed.

Now you have a mode the purpose of which is to limit commands to a
region that has been made active.  To make a region active, you have to
select it, so you're actually making a selection.  This mode is already
inconsistent because it allows commands to do things with a region even
when there is no active region, so these commands may do random things
because the region is a random thing.

You take that even further by having commands that imply doing something
only with a region.  Why would you expect a user who is working in a
mode that limits commands doing things with a region to doing them with
a selection to want to use commands implying they do something with a
region?  Why would you expect this user who wants to work with
selections rather than with regions to want to work with regions
instead?

At least there needs to be a replacement for upcase-region and the like
that work with the selection.  In case of upcase-region, it could be
called upcase.  That would bring more consistency.


BTW, upcase-dwim is flawed because it *extends* to the active region
*if* the region contains more than one word.  That contradicts
transient-mark-mode and requires another state besides "limiting":
"extending".  However, upcase-dwim is also limited to the active region,
so "limiting" together with "extending" can become a problem for region
states because it becomes unclear again what exactly is desired.

>> It's a clash between transient-mark-mode enabled and disabled.  In one
>> case, the behaviour is a bug because the mode suggests that commands
>> doing something must not do it with regions but with selections (active
>> regions); in the other, it's fine because there is always something for
>> commands that do something with something to do what they do because
>> there's always a region, and the second case implies that it is
>> generally fine for software to make mistakes of the users worse rather
>> than protecting them from them.
>> 
>> Actually, the second case is merely a slip-up, like driving your car
>> into the wall at full throttle and no seat belts on, either just because
>> you can, or unintentionally.  For some reason, only with
>> transient-mark-mode enabled, this becomes obvious because it has been
>> overlooked at least for the unintentional variant.  It probably was
>> never wanted even without transient-mark-mode, i. e. the intentional
>> variant.
>
> "Parse error".  "One case"? "second case"?  What is this about?

The two cases are the different results of the different behaviours
caused by transient-mark-mode either enabled or disabled, as
described. The same behaviour can be a bug or a design flaw, depending
on t-m-m. That refers to operations that imply doing something with a
region, like downcase-region.

The design flaw was probably never intended.

>> Or why would I want something like upcase-region to suddenly mess up
>> random parts of a buffer?
>
> Only they aren't random.

They are as random as the region, and the region is entirely random.

>> A region is not a selection, it's only a random part of the buffer
>> that has somehow gotten between mark and point, perhaps when mark
>> and point were used for navigation, or when I moved around, or when
>> the mark happened to be set somewhere last time I yanked something,
>> or when the cat stepped over the keyboard while I was pressing Ctrl
>> or when it hit the cursor keys ...
>
> The region _is_ selection in Emacs.

That's the problem ...

> If you want Emacs to do something with text in the region, you will
> redefine the region before invoking the command

I always do that.  That's "making a selection", and it's the selection I
work with, not the region.  The only time the region is not random is
when it is a(n active) selection.

> -- unless you know the region is already set up as you want it,
> e.g. because you have just yanked the text to which you want to apply
> the command.

I work with selections, not with regions.  I can't even see the region.
Before I yank text, the selection is gone because it goes away when
copying.

> This is exactly why region and its integration with commands in Emacs
> is a very valuable feature.

How is this inflexibility a valuable feature?

>> > Other commands, which make sense both when there is and there isn't a
>> > region, need an indication of what the user wants them to do, and
>> > whether the region is active is that indication.
>> 
>> The indication is whether there is a selection or not.
>
> Same thing.

No, there is a big difference between a selection and a highlighted
region.

>> The problem is the region.  It's not needed for anything and keeps
>> getting in the way.
>
> Not in Emacs, it isn't.

It is *the* problem.

RE: delete-selection-mode as default

[Drew Adams]

> nobody would use d-s-m without t-m-m unless they wanted to do
> something that doesn't make sense.

Actually, d-s-m requires t-m-m. It turns it on, and each time you try
to use it it checks that t-m-m is on (if not, it does nothing).

> transient-mark-mode says that commands should be limited to the "active"
> region. 

No, it does not. It simply says that, when it is enabled:

   "the region is highlighted when the mark is active.
    ...
    Many commands change their behavior when Transient Mark mode is
    in effect and the mark is active, by acting on the region instead..."

(That's from `C-h f transient-mark-mode'. Similarly for (emacs) `Disabled
Transient Mark' and (elisp)`The Mark'.)

Re: delete-selection-mode as default

[hw]

Drew Adams <drew.adams@oracle.com> writes:

>> nobody would use d-s-m without t-m-m unless they wanted to do
>> something that doesn't make sense.
>
> Actually, d-s-m requires t-m-m. It turns it on, and each time you try
> to use it it checks that t-m-m is on (if not, it does nothing).

That makes sense.

>> transient-mark-mode says that commands should be limited to the "active"
>> region. 
>
> No, it does not. It simply says that, when it is enabled:
>
>    "the region is highlighted when the mark is active.
>     ...
>     Many commands change their behavior when Transient Mark mode is
>     in effect and the mark is active, by acting on the region instead..."
>
> (That's from `C-h f transient-mark-mode'. Similarly for (emacs) `Disabled
> Transient Mark' and (elisp)`The Mark'.)

Right, it does not very explicitly say that.

Yet the distinction is "operating on the region" vs. "operating on the
buffer".  That is effectively a limitation unless you select the whole
buffer.

I suspect a limitation was the original idea and intention of
transient-mark-mode while an extension was not.  An extension wasn't
even needed, so why would it have been intended?  It probably never came
to mind.  Maybe someone knows for sure.


In any case, isn't it useful for clarification to make a distinction
between limiting and extending?

Please explain why upcase-word is not extended to the active region but
upcase-dwim is.  The description of upcase-word doesn't say what effect
transient-mark-mode and a(n active) region has on it.  Shouldn't that be
clarified?

Re: delete-selection-mode as default

[Eli Zaretskii]

> From: hw <hw@adminart.net>
> Cc: spacibba@aol.com,  joostkremers@fastmail.fm,  npostavs@gmail.com,  emacs-devel@gnu.org,  yurivkhan@gmail.com,  acm@muc.de,  drew.adams@oracle.com,  phillip.lord@russet.org.uk
> Date: Tue, 18 Sep 2018 00:11:05 +0200
> 
> >> 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.
> >
> > You forget the kill-ring and the kill/yank commands.  Those are almost
> > exactly identical to what other apps give you with copy/paste, and the
> > latter use selections.  So the reasons Emacs implements selections
> > using the region are more fundamental than just navigation.
> 
> What are these fundamental reasons?

They were just described above: the set of commands that copy/kill and
paste text.

> Other programs, like joe, allow you to use the selection for
> navigation without having a region.

Once again, in Emacs region _is_ the selection.

> > Once again: in Emacs, selection _is_ the region, and for some very
> > good reasons.
> 
> Not to me.  The selection is what becomes highlighted when I make one.

That's a minor detail in Emacs.  The underlying fundamental
functionality is the region.

> > You can, of course, start inventing an Emacs that is based on
> > selections.  But if that Emacs will still support copy/paste inside
> > Emacs and vis-a-vis other apps, if it will support commands that
> > operate on the selected text and/or work different when some text is
> > selected -- then what you will have at the end is the same Emacs, just
> > one where the region is called "selection".  OK, maybe you will lose
> > the ability to do "C-x C-x" for navigation -- but to what purpose?
> 
> I never use that, why would I?

Others do.  Emacs caters to many different workflows, and it is fine
not to have to use some of its features for which you don't have a
need.  But we cannot remove them just because you personally don't use
them, can we?

> Do you mean the one that solves some problems with delete-selection-mode
> by "arming" the region instead of activating it?  I'd rather call it
> "disarming" because disarming before killing makes more sense than
> arming before killing :)
> 
> IIUC, your idea is to *generally* either "activate" a region or to
> "disarm" it, depending on which behaviour a user wants.  I'm not sure
> how this is different from delete-selection-mode, and I think it needs
> more variations:
> 
> By setting mark-even-if-inactive to nil, I have "fortified" the region
> because nothing can be done with it unless it is "active".
> 
> There are more variations, like disabling shift-selection and disabling
> making a selection with the trackball.  That might make the region
> "protected".  When it's also fortified, it would be "inert", unless it
> has been disarmed, in which case it would be "content".

These word plays just muddy the waters.  The basic point is to have
more than just 2 states of the region, and allow various features
behave differently by being sensitive to the current state of the
region.

> I like the idea because having a domain of fundamental region states
> that can be combined with each other can lead to more consistency, and
> the whole domain could be explained to users so they can get the
> behaviour they prefer by picking any combination of states.  Currently,
> all the modes and options involved appear to be unrelated, and users may
> never find what suits them best because they don't know all the
> available options.  Bringing them together in one domain would change
> that.

Good, so we agree.

> They actually *are* two different things for me.  The selection is what
> I make to work with and what becomes highlighted.  The region is
> something unwanted always lurking in the background waiting for me to
> make a mistake and making me feel uneasy.
> 
> The problem is that Emacs is unable to make this important distinction.
> I could say that this confuses things.

Because in Emacs, selection _is_ the region.  Adding a state property
could allow us to make the distinction nonetheless.

> Navigating a buffer and making selections are two totally unrelated
> things.

No, they are closely related, because in general you need to navigate
to a place to mark it as beginning/ending a selection.

> > You are missing the point.  The point is that sometimes the user
> > doesn't want a selection to be replaced by a character she types, and
> > other times she does.  The issue at hand is how to design a UI that
> > will allow both possibilities, without telling the users to turn on or
> > off delete-selection-mode for that purpose.
> 
> Do you mean there is a big problem with delete-selection-mode when
> transient-mark-mode is disabled because then there is "maybe sometimes"
> a selection a user may want to replace by inserting characters?

No, I mean delete-selection-mode changes the effects of some commands
in ways that could be very inconvenient in some situations, and
currently the only way for the user to deal with such conflicts is by
turning on or off delete-selection-mode.  There should be a better way
of temporarily enabling/disabling delete-selection-mode, similar to
what we have for transient-mark-mode.

> Other than that, Emacs would have to read the users` minds to figure out
> what they want with each character they insert.

See above: I believe we can let the users speak their minds so that
Emacs doesn't need to read them.

> Upcase-region works without activating the region first though
> transient-mark-mode says that commands should be limited to the "active"
> region.  So for upcase-region to work when no region is "active", it is
> as if the region is secretly activated so that upcase-region can work,
> and this may be unexpected.

What do you want upcase-region to do when there's no active region,
then?  Doing nothing or signaling an error would go against Emacs's
tradition of DWIM-ish operation.

> > This flies in the face of a long tradition in Emacs to provide DWIMish
> > operation, whereby if something makes a lot of sense in some
> > specialized situation, Emacs should do that automatically, even if it
> > deviates from the "normal" operation.  A notable example is what C-t
> > does when point is at end of line.
> >
> > So if some effect of a command would make sense when it is invoked
> > without any "selection", we program Emacs to do that, and that is not
> > a bug at all, it's why Emacs shines in many situations where other
> > editors don't.
> 
> That's a difficult thing because it creates inconsistencies.

If what Emacs does is what the user would expect, what makes sense,
then the inconsistencies don't matter.

> >> Or why would I want something like upcase-region to suddenly mess up
> >> random parts of a buffer?
> >
> > Only they aren't random.
> 
> They are as random as the region, and the region is entirely random.

I disagree.  IME, it is never random when I want to act on it.

> > If you want Emacs to do something with text in the region, you will
> > redefine the region before invoking the command
> 
> I always do that.  That's "making a selection", and it's the selection I
> work with, not the region.  The only time the region is not random is
> when it is a(n active) selection.

Which always happens before you invoke a command that works on a
region.  And in some case, the region is already conveniently set to
what you might want to act upon.

Re: delete-selection-mode as default

[Yuri Khan]

On Tue, Sep 18, 2018 at 7:32 PM Eli Zaretskii <eliz@gnu.org> wrote:

> No, I mean delete-selection-mode changes the effects of some commands
> in ways that could be very inconvenient in some situations, and
> currently the only way for the user to deal with such conflicts is by
> turning on or off delete-selection-mode.  There should be a better way
> of temporarily enabling/disabling delete-selection-mode, similar to
> what we have for transient-mark-mode.

What changes by delete-selection-mode cannot be worked around by
(temporarily) deactivating the region?


Initial state: some text before point is selected. We want to insert
some text without replacing the selection.

C-g <type some text> C-S-g

Result: the same text + newly typed text is selected.


Initial state: some text after point is selected. We want to yank
something without replacing the selection.

C-g C-y C-S-g

Result: kill ring content inserted, same text is selected.


(I am assuming C-S-g is bound to a command that activates the mark and
does nothing else.)

Re: delete-selection-mode as default

[Eli Zaretskii]

> From: Yuri Khan <yurivkhan@gmail.com>
> Date: Tue, 18 Sep 2018 20:14:41 +0700
> Cc: hw@adminart.net, spacibba@aol.com, 
> 	Joost Kremers <joostkremers@fastmail.fm>, Noam Postavsky <npostavs@gmail.com>, 
> 	Emacs developers <emacs-devel@gnu.org>, Alan Mackenzie <acm@muc.de>, Drew Adams <drew.adams@oracle.com>, 
> 	Phillip Lord <phillip.lord@russet.org.uk>
> 
> On Tue, Sep 18, 2018 at 7:32 PM Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > No, I mean delete-selection-mode changes the effects of some commands
> > in ways that could be very inconvenient in some situations, and
> > currently the only way for the user to deal with such conflicts is by
> > turning on or off delete-selection-mode.  There should be a better way
> > of temporarily enabling/disabling delete-selection-mode, similar to
> > what we have for transient-mark-mode.
> 
> What changes by delete-selection-mode cannot be worked around by
> (temporarily) deactivating the region?

Deactivating the region makes it disappear from view, which I think we
should avoid.  Users will not expect the region to disappear.
Moreover, this is currently impossible, because your fictional C-S-g
command doesn't exist.

> Initial state: some text before point is selected. We want to insert
> some text without replacing the selection.
> 
> C-g <type some text> C-S-g
> 
> Result: the same text + newly typed text is selected.

If we are going to introduce a command for temporarily disabling or
re-enabling the region, we had better do it without making it
disappear from display, IMO.

But in general, yes, that's the idea: introduce a state of the region
whereby delete-selection-mode is temporarily suspended.

Re: delete-selection-mode as default

[Yuri Khan]

On Tue, Sep 18, 2018 at 9:16 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > What changes by delete-selection-mode cannot be worked around by
> > (temporarily) deactivating the region?
>
> Deactivating the region makes it disappear from view, which I think we
> should avoid.  Users will not expect the region to disappear.
> Moreover, this is currently impossible, because your fictional C-S-g
> command doesn't exist.

Well, your hypothetical “disable-delete-selection-mode-temporarily”
does not exist either.

> If we are going to introduce a command for temporarily disabling or
> re-enabling the region, we had better do it without making it
> disappear from display, IMO.

As a user of transient-mark-mode, shift-select-mode and
delete-selection-mode, I’d expect to be among the target audience for
this facility being discussed. But, strangely, I very rarely find
myself in a situation where I have an active region that I want to
preserve for later while wanting to type something. I am certainly
okay with temporarily deactivating the mark and the region
highlighting, if I know I’ll be easily able to re-activate it.

How would a command to temporarily suspend delete-selection-mode work?
I assume the user will have to press at least one key to invoke it.
Then, I expect there will be an unpredictable sequence of self-insert
and/or yank and/or other editing commands, so the user will also
indicate the moment when he/she wants delete-selection-mode back. At
this point, it is not going to be any more efficient than just binding
delete-selection-mode to an easy key or binding C-S-g to (lambda ()
(interactive) (activate-mark)); each of these takes one keypress
before and one keypress after typing-without-replacing-selection.

Also, a user who enables and disables d-s-m often would need some kind
of indication of its current status — either a modeline lighter or a
special face for the region when it is active but will not be replaced
by typing.

RE: delete-selection-mode as default

[Drew Adams]

> > If we are going to introduce a command for temporarily disabling or
> > re-enabling the region, we had better do it without making it
> > disappear from display, IMO.
> 
> As a user of transient-mark-mode, shift-select-mode and
> delete-selection-mode, I’d expect to be among the target audience for
> this facility being discussed. But, strangely, I very rarely find
> myself in a situation where I have an active region that I want to
> preserve for later while wanting to type something. I am certainly
> okay with temporarily deactivating the mark and the region
> highlighting, if I know I’ll be easily able to re-activate it.
> 
> How would a command to temporarily suspend delete-selection-mode
> work?
> I assume the user will have to press at least one key to invoke it.
> Then, I expect there will be an unpredictable sequence of self-insert
> and/or yank and/or other editing commands, so the user will also
> indicate the moment when he/she wants delete-selection-mode back. At
> this point, it is not going to be any more efficient than just binding
> delete-selection-mode to an easy key or binding C-S-g to (lambda ()
> (interactive) (activate-mark)); each of these takes one keypress
> before and one keypress after typing-without-replacing-selection.
> 
> Also, a user who enables and disables d-s-m often would need some kind
> of indication of its current status — either a modeline lighter or a
> special face for the region when it is active but will not be replaced
> by typing.

FWIW, Yuri said exactly what I would have said.

What's the real use case for such temporary enabling/disabling of d-s-m? And how is it different from just, well, enabling/disabling d-s-m?

You've said that you guess that at least some people will want to take advantage of d-s-m sometimes and sometimes not use it. OK, but maybe an example would help.

In any case, how do you envision enabling/disabling d-s-m as something different from turning d-s-m on/off? If you want some key(s) to enable/disable it, how is that different from just binding a key (or keys) to `delete-selection-mode'?

Re: delete-selection-mode as default

[Eli Zaretskii]

> Date: Tue, 18 Sep 2018 08:37:12 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: hw@adminart.net, spacibba@aol.com,
>         Joost Kremers
>  <joostkremers@fastmail.fm>,
>         Noam Postavsky <npostavs@gmail.com>,
>         Emacs
>  developers <emacs-devel@gnu.org>, Alan Mackenzie <acm@muc.de>,
>         Phillip Lord
>  <phillip.lord@russet.org.uk>
> 
> What's the real use case for such temporary enabling/disabling of d-s-m? And how is it different from just, well, enabling/disabling d-s-m?

People who are against turning on delete-selection-mode presented
several such use cases.

> In any case, how do you envision enabling/disabling d-s-m as something different from turning d-s-m on/off? If you want some key(s) to enable/disable it, how is that different from just binding a key (or keys) to `delete-selection-mode'?

Why don't you ask the same question about transient-mark-mode?  My
idea was to extend the feature of region activation, which would avoid
the need for turning on and off the mode.

Re: delete-selection-mode as default

[Eli Zaretskii]

> From: Yuri Khan <yurivkhan@gmail.com>
> Date: Tue, 18 Sep 2018 22:28:23 +0700
> Cc: hw@adminart.net, spacibba@aol.com, 
> 	Joost Kremers <joostkremers@fastmail.fm>, Noam Postavsky <npostavs@gmail.com>, 
> 	Emacs developers <emacs-devel@gnu.org>, Alan Mackenzie <acm@muc.de>, Drew Adams <drew.adams@oracle.com>, 
> 	Phillip Lord <phillip.lord@russet.org.uk>
> 
> On Tue, Sep 18, 2018 at 9:16 PM Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > > What changes by delete-selection-mode cannot be worked around by
> > > (temporarily) deactivating the region?
> >
> > Deactivating the region makes it disappear from view, which I think we
> > should avoid.  Users will not expect the region to disappear.
> > Moreover, this is currently impossible, because your fictional C-S-g
> > command doesn't exist.
> 
> Well, your hypothetical “disable-delete-selection-mode-temporarily”
> does not exist either.

Of course, it isn't.  We are discussing what should we add to Emacs to
make such actions possible.  And my point is that as long as we are
adding a feature, it would be better if it did not deactivate region,
because doing so have certain disadvantages.

> > If we are going to introduce a command for temporarily disabling or
> > re-enabling the region, we had better do it without making it
> > disappear from display, IMO.
> 
> As a user of transient-mark-mode, shift-select-mode and
> delete-selection-mode, I’d expect to be among the target audience for
> this facility being discussed. But, strangely, I very rarely find
> myself in a situation where I have an active region that I want to
> preserve for later while wanting to type something. I am certainly
> okay with temporarily deactivating the mark and the region
> highlighting, if I know I’ll be easily able to re-activate it.

Then perhaps we should have 2 variants of such a command, one that
deactivates the region and another that doesn't.

> How would a command to temporarily suspend delete-selection-mode work?
> I assume the user will have to press at least one key to invoke it.
> Then, I expect there will be an unpredictable sequence of self-insert
> and/or yank and/or other editing commands, so the user will also
> indicate the moment when he/she wants delete-selection-mode back. At
> this point, it is not going to be any more efficient than just binding
> delete-selection-mode to an easy key or binding C-S-g to (lambda ()
> (interactive) (activate-mark)); each of these takes one keypress
> before and one keypress after typing-without-replacing-selection.

It is not more efficient, but leaving the region highlighted might be
preferable for use cases you don't care about.

> Also, a user who enables and disables d-s-m often would need some kind
> of indication of its current status — either a modeline lighter or a
> special face for the region when it is active but will not be replaced
> by typing.

Agreed.

Re: delete-selection-mode as default

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > some text without replacing the selection.

  > C-g <type some text> C-S-g

If C-S-g were given a suitable definition, 
that command sequence would do what you have in mind.

However, it requires typing two extra characters, so it is an
inconvenience in something that is currently easy and natural.
It also requires remembering more.

Sorry, I won't go along.



-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: delete-selection-mode as default

[Yuri Khan]

On Thu, Sep 20, 2018 at 8:46 AM Richard Stallman <rms@gnu.org> wrote:

>   > some text without replacing the selection.
>
>   > C-g <type some text> C-S-g
>
> If C-S-g were given a suitable definition,
> that command sequence would do what you have in mind.
>
> However, it requires typing two extra characters, so it is an
> inconvenience in something that is currently easy and natural.
> It also requires remembering more.

You are using the current default Emacs behavior
(delete-selection-mode off) as the baseline for comparison. In that
setup, yes, you can insert text right away.

However, the context of discussion is when delete-selection-mode is
on. In that setup, typing new text replaces the selection, and the
assumption is that most new users expect that and want that behavior
most of the time. So, in the rare case that one wants to insert text
without replacing the active region, one has two options:

a) Disable delete-selection-mode temporarily, insert new text, and
then enable d-s-m again. This takes a minimum of two extra key
presses, if d-s-m is bound to a key; more if it isn’t.

b) Deactivate the region, insert new text, then reactivate the region.

b0) As far as I can tell, currently, the most economical way to do
that is C-g then C-x C-x (three extra key presses), and it has a side
effect of exchanging mark and point.

b1) A novice user will typically deactivate the region by doing a
dummy point movement, either by clicking at the point, or by two
mutually canceling motions: <left> <right>. After inserting new text,
if they still need the region to be active, they will most probably
re-select it, with whatever selection gesture they are used to (mouse
or shift-selection).

So my suggestion is no worse than the existing solutions.

Re: delete-selection-mode as default

[hw]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: hw <hw@adminart.net>
>> Cc: spacibba@aol.com, joostkremers@fastmail.fm, npostavs@gmail.com,
>> emacs-devel@gnu.org, yurivkhan@gmail.com, acm@muc.de,
>> drew.adams@oracle.com, phillip.lord@russet.org.uk
>> Date: Tue, 18 Sep 2018 00:11:05 +0200
>> 
>> >> 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.
>> >
>> > You forget the kill-ring and the kill/yank commands.  Those are almost
>> > exactly identical to what other apps give you with copy/paste, and the
>> > latter use selections.  So the reasons Emacs implements selections
>> > using the region are more fundamental than just navigation.
>> 
>> What are these fundamental reasons?
>
> They were just described above: the set of commands that copy/kill and
> paste text.

I don't understand how being able to cut and paste selections becomes
more fundamental than being able to navigate because all of those use
the same fundamental concept.

>> Other programs, like joe, allow you to use the selection for
>> navigation without having a region.
>
> Once again, in Emacs region _is_ the selection.
>
>> > Once again: in Emacs, selection _is_ the region, and for some very
>> > good reasons.
>> 
>> Not to me.  The selection is what becomes highlighted when I make one.
>
> That's a minor detail in Emacs.  The underlying fundamental
> functionality is the region.

The distinction between a (the) selection and a (the) region is
important and not a minor detail.  For this distinction, it is pretty
irrelevant how both are implemented.

For practical usage, how both are implemented can be relevant.

>> > You can, of course, start inventing an Emacs that is based on
>> > selections.  But if that Emacs will still support copy/paste inside
>> > Emacs and vis-a-vis other apps, if it will support commands that
>> > operate on the selected text and/or work different when some text is
>> > selected -- then what you will have at the end is the same Emacs, just
>> > one where the region is called "selection".  OK, maybe you will lose
>> > the ability to do "C-x C-x" for navigation -- but to what purpose?
>> 
>> I never use that, why would I?
>
> Others do.  Emacs caters to many different workflows, and it is fine
> not to have to use some of its features for which you don't have a
> need.  But we cannot remove them just because you personally don't use
> them, can we?

I'm not suggesting to remove them.

>> Do you mean the one that solves some problems with delete-selection-mode
>> by "arming" the region instead of activating it?  I'd rather call it
>> "disarming" because disarming before killing makes more sense than
>> arming before killing :)
>> 
>> IIUC, your idea is to *generally* either "activate" a region or to
>> "disarm" it, depending on which behaviour a user wants.  I'm not sure
>> how this is different from delete-selection-mode, and I think it needs
>> more variations:
>> 
>> By setting mark-even-if-inactive to nil, I have "fortified" the region
>> because nothing can be done with it unless it is "active".
>> 
>> There are more variations, like disabling shift-selection and disabling
>> making a selection with the trackball.  That might make the region
>> "protected".  When it's also fortified, it would be "inert", unless it
>> has been disarmed, in which case it would be "content".
>
> These word plays just muddy the waters.

It is sometimes an advantage when you can give something a name because
the name can make it easier to understand and to remember.  For example,
"fortified" may be easier to remember than "state 00000101" or "state 5".

> The basic point is to have more than just 2 states of the region, and
> allow various features behave differently by being sensitive to the
> current state of the region.
>
>> I like the idea because having a domain of fundamental region states
>> that can be combined with each other can lead to more consistency, and
>> the whole domain could be explained to users so they can get the
>> behaviour they prefer by picking any combination of states.  Currently,
>> all the modes and options involved appear to be unrelated, and users may
>> never find what suits them best because they don't know all the
>> available options.  Bringing them together in one domain would change
>> that.
>
> Good, so we agree.

I'm not sure, it seems to me that your idea is much different from how I
thought it was.

Do you mean the state to be general, like a default, or to be changed
all the time depending on what a user wants and does?  I suppose there
would have to be some kind of default, and if users needed to change it
or to somehow work around it all the time, it wouldn't look like a good
default to me.

>> They actually *are* two different things for me.  The selection is what
>> I make to work with and what becomes highlighted.  The region is
>> something unwanted always lurking in the background waiting for me to
>> make a mistake and making me feel uneasy.
>> 
>> The problem is that Emacs is unable to make this important distinction.
>> I could say that this confuses things.
>
> Because in Emacs, selection _is_ the region.  Adding a state property
> could allow us to make the distinction nonetheless.

You could consider transient-mark-mode as a state.  How would you deal
with its variations, are they states on their own?

>> Navigating a buffer and making selections are two totally unrelated
>> things.
>
> No, they are closely related, because in general you need to navigate
> to a place to mark it as beginning/ending a selection.

There are many other reasons to navigate than making selections.  Having
to go somewhere to make one is a special case and might not even fall
under navigation because you can have navigated close to where you then
make a selection.  That means you're already there for other reasons and
just need to move a little.  There is a distinction between navigating
and making a selection.

>> > You are missing the point.  The point is that sometimes the user
>> > doesn't want a selection to be replaced by a character she types, and
>> > other times she does.  The issue at hand is how to design a UI that
>> > will allow both possibilities, without telling the users to turn on or
>> > off delete-selection-mode for that purpose.
>> 
>> Do you mean there is a big problem with delete-selection-mode when
>> transient-mark-mode is disabled because then there is "maybe sometimes"
>> a selection a user may want to replace by inserting characters?
>
> No, I mean delete-selection-mode changes the effects of some commands
> in ways that could be very inconvenient in some situations, and
> currently the only way for the user to deal with such conflicts is by
> turning on or off delete-selection-mode.  There should be a better way
> of temporarily enabling/disabling delete-selection-mode, similar to
> what we have for transient-mark-mode.

What if the commands were automatically prevented from having
inconvenient effects?

>> Other than that, Emacs would have to read the users` minds to figure out
>> what they want with each character they insert.
>
> See above: I believe we can let the users speak their minds so that
> Emacs doesn't need to read them.

The amount of key bindings users are willing to learn and the number of
defaults they are willing to change or to work around may be limited.

>> Upcase-region works without activating the region first though
>> transient-mark-mode says that commands should be limited to the "active"
>> region.  So for upcase-region to work when no region is "active", it is
>> as if the region is secretly activated so that upcase-region can work,
>> and this may be unexpected.
>
> What do you want upcase-region to do when there's no active region,
> then?  Doing nothing or signaling an error would go against Emacs's
> tradition of DWIM-ish operation.

The equivalent of not having a region when `transient-mark-mode' is
disabled is not having an active region when `transient-mark-mode' is
enabled.  When `upcase-region' is called while the mark is nil, Emacs
signals an error.  Hence, when `transient-mark-mode' is enabled and the
region is not active, `upcase-region' should signal an error.

With transient-mark-mode enabled, the default should be
mark-even-if-inactive set to nil.  That would be more consistent: with
this, Emacs signals an error when `upcase-region' is called while the
region is not active.

It's quite the enhancement `transient-mark-mode' can provide: it allows
to actually fortify the region against accidental use.  How can that be
done when `transient-mark-mode' is disabled?


Maybe you could consider this as an example for the "state idea" because
it comes down to what the user wants.  It's a default the user does not
need to and will not want to work around, though.

>> > This flies in the face of a long tradition in Emacs to provide DWIMish
>> > operation, whereby if something makes a lot of sense in some
>> > specialized situation, Emacs should do that automatically, even if it
>> > deviates from the "normal" operation.  A notable example is what C-t
>> > does when point is at end of line.
>> >
>> > So if some effect of a command would make sense when it is invoked
>> > without any "selection", we program Emacs to do that, and that is not
>> > a bug at all, it's why Emacs shines in many situations where other
>> > editors don't.
>> 
>> That's a difficult thing because it creates inconsistencies.
>
> If what Emacs does is what the user would expect, what makes sense,
> then the inconsistencies don't matter.

When the user starts thinking about things, they can suddenly start to
matter.  Upcase-region and mark-even-if-inactive non-nil by default is a
good example.

>> >> Or why would I want something like upcase-region to suddenly mess up
>> >> random parts of a buffer?
>> >
>> > Only they aren't random.
>> 
>> They are as random as the region, and the region is entirely random.
>
> I disagree.  IME, it is never random when I want to act on it.

When you want to act on it, you have probably taken care so that it
isn't random before you act.  How is that different from making a
selection to do something with before doing it?

I'm assuming you don't want to do something with random parts of a
buffer, and you seem to have confirmed that.

>> > If you want Emacs to do something with text in the region, you will
>> > redefine the region before invoking the command
>> 
>> I always do that.  That's "making a selection", and it's the selection I
>> work with, not the region.  The only time the region is not random is
>> when it is a(n active) selection.
>
> Which always happens before you invoke a command that works on a
> region.

The selection I want to do something with doesn't form itself because it
somehow just so happens.

> And in some case, the region is already conveniently set to what you
> might want to act upon.

And I don't know when this happens because there is no indication of it.
I might see it if the mark was visible and/or if point were to show the
imaginary tail.

I wouldn't mind writing something for it, but I have no idea where to
start.

Re: delete-selection-mode as default

[Eli Zaretskii]

> From: hw <hw@adminart.net>
> Cc: spacibba@aol.com,  joostkremers@fastmail.fm,  npostavs@gmail.com,  emacs-devel@gnu.org,  yurivkhan@gmail.com,  acm@muc.de,  drew.adams@oracle.com,  phillip.lord@russet.org.uk
> Date: Wed, 19 Sep 2018 04:26:45 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: hw <hw@adminart.net>
> >> Cc: spacibba@aol.com, joostkremers@fastmail.fm, npostavs@gmail.com,
> >> emacs-devel@gnu.org, yurivkhan@gmail.com, acm@muc.de,
> >> drew.adams@oracle.com, phillip.lord@russet.org.uk
> >> Date: Tue, 18 Sep 2018 00:11:05 +0200
> >> 
> >> >> 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.
> >> >
> >> > You forget the kill-ring and the kill/yank commands.  Those are almost
> >> > exactly identical to what other apps give you with copy/paste, and the
> >> > latter use selections.  So the reasons Emacs implements selections
> >> > using the region are more fundamental than just navigation.
> >> 
> >> What are these fundamental reasons?
> >
> > They were just described above: the set of commands that copy/kill and
> > paste text.
> 
> I don't understand how being able to cut and paste selections becomes
> more fundamental than being able to navigate because all of those use
> the same fundamental concept.

It means if you lose the current meaning of the region, you also lose
the cut/copy/paste commands, and their history on the kill-ring.

> >> > Once again: in Emacs, selection _is_ the region, and for some very
> >> > good reasons.
> >> 
> >> Not to me.  The selection is what becomes highlighted when I make one.
> >
> > That's a minor detail in Emacs.  The underlying fundamental
> > functionality is the region.
> 
> The distinction between a (the) selection and a (the) region is
> important and not a minor detail.  For this distinction, it is pretty
> irrelevant how both are implemented.

This whole thread came to the existent because the underlying
implementation is NOT irrelevant.

> Do you mean the state to be general, like a default, or to be changed
> all the time depending on what a user wants and does?  I suppose there
> would have to be some kind of default, and if users needed to change it
> or to somehow work around it all the time, it wouldn't look like a good
> default to me.

That's the idea, but since the default should be OK most of the time,
the need to override it should be rare.

> You could consider transient-mark-mode as a state.  How would you deal
> with its variations, are they states on their own?

For transient-mark-mode, the states are active and inactive.  So a
command that toggles the state would be something I have in mind.

> > No, I mean delete-selection-mode changes the effects of some commands
> > in ways that could be very inconvenient in some situations, and
> > currently the only way for the user to deal with such conflicts is by
> > turning on or off delete-selection-mode.  There should be a better way
> > of temporarily enabling/disabling delete-selection-mode, similar to
> > what we have for transient-mark-mode.
> 
> What if the commands were automatically prevented from having
> inconvenient effects?

That'd be nice, but I don't believe there's a way to do that without
adversely affecting other important features.  Hence I propose to
place on the user the burden of preventing Emacs from having those
inconvenient effects, assuming that each user chooses their defaults
such that in most cases Emacs already does what the user expects.

Re: delete-selection-mode as default

[hw]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: hw <hw@adminart.net>
>> Cc: spacibba@aol.com, joostkremers@fastmail.fm, npostavs@gmail.com,
>> emacs-devel@gnu.org, yurivkhan@gmail.com, acm@muc.de,
>> drew.adams@oracle.com, phillip.lord@russet.org.uk
>> Date: Wed, 19 Sep 2018 04:26:45 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> From: hw <hw@adminart.net>
>> >> Cc: spacibba@aol.com, joostkremers@fastmail.fm, npostavs@gmail.com,
>> >> emacs-devel@gnu.org, yurivkhan@gmail.com, acm@muc.de,
>> >> drew.adams@oracle.com, phillip.lord@russet.org.uk
>> >> Date: Tue, 18 Sep 2018 00:11:05 +0200
>> >> 
>> >> >> 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.
>> >> >
>> >> > You forget the kill-ring and the kill/yank commands.  Those are almost
>> >> > exactly identical to what other apps give you with copy/paste, and the
>> >> > latter use selections.  So the reasons Emacs implements selections
>> >> > using the region are more fundamental than just navigation.
>> >> 
>> >> What are these fundamental reasons?
>> >
>> > They were just described above: the set of commands that copy/kill and
>> > paste text.
>> 
>> I don't understand how being able to cut and paste selections becomes
>> more fundamental than being able to navigate because all of those use
>> the same fundamental concept.
>
> It means if you lose the current meaning of the region, you also lose
> the cut/copy/paste commands, and their history on the kill-ring.

They could just work with the selection instead.

>> >> > Once again: in Emacs, selection _is_ the region, and for some very
>> >> > good reasons.
>> >> 
>> >> Not to me.  The selection is what becomes highlighted when I make one.
>> >
>> > That's a minor detail in Emacs.  The underlying fundamental
>> > functionality is the region.
>> 
>> The distinction between a (the) selection and a (the) region is
>> important and not a minor detail.  For this distinction, it is pretty
>> irrelevant how both are implemented.
>
> This whole thread came to the existent because the underlying
> implementation is NOT irrelevant.

Is the implementation relevant for the distinction?  The distinction
between a region and a selection exists regardless of the implementation
of each.

>> Do you mean the state to be general, like a default, or to be changed
>> all the time depending on what a user wants and does?  I suppose there
>> would have to be some kind of default, and if users needed to change it
>> or to somehow work around it all the time, it wouldn't look like a good
>> default to me.
>
> That's the idea, but since the default should be OK most of the time,
> the need to override it should be rare.

ok

>> You could consider transient-mark-mode as a state.  How would you deal
>> with its variations, are they states on their own?
>
> For transient-mark-mode, the states are active and inactive.  So a
> command that toggles the state would be something I have in mind.

The meaning of these states can vary through different behaviour
resulting from changes to variables like delete-active-region and
mark-even-if-inactive.  These changes go so far as to make for different
defaults on their own.

A command that glides through all possible combinations of states and/or
all possible defaults may have so many combinations to glide through that it
would be troublesome to use.  But if states/defaults could be stored in
registers, users could quickly switch between those relevant for them.

>> > No, I mean delete-selection-mode changes the effects of some commands
>> > in ways that could be very inconvenient in some situations, and
>> > currently the only way for the user to deal with such conflicts is by
>> > turning on or off delete-selection-mode.  There should be a better way
>> > of temporarily enabling/disabling delete-selection-mode, similar to
>> > what we have for transient-mark-mode.
>> 
>> What if the commands were automatically prevented from having
>> inconvenient effects?
>
> That'd be nice, but I don't believe there's a way to do that without
> adversely affecting other important features.

What would be an example for this?

> Hence I propose to place on the user the burden of preventing Emacs
> from having those inconvenient effects, assuming that each user
> chooses their defaults such that in most cases Emacs already does what
> the user expects.

RE: delete-selection-mode as default

[Drew Adams]

> > What's the real use case for such temporary enabling/disabling of d-s-m?
> > And how is it different from just, well, enabling/disabling d-s-m?
> 
> People who are against turning on delete-selection-mode presented
> several such use cases.

I don't think so. I think you just postulated it, without any example.
Did someone who is against using d-s-m actually say that s?he
wanted to use it temporarily (and without turning d-s-m on,
whatever that means)?

But I could be wrong - it's a long thread. Feel free to point us to
some mention by someone of such a use case. Or if that's not
possible, please remind us of (describe) such a case.

> > In any case, how do you envision enabling/disabling d-s-m as something
> > different from turning d-s-m on/off? If you want some key(s) to
> > enable/disable it, how is that different from just binding a key 
> > (or keys) to `delete-selection-mode'?
> 
> Why don't you ask the same question about transient-mark-mode?

Why do you think I should do that? What are you driving at?
I don't have such a question about t-m-m.

You seem to be proposing enabling/disabling d-s-m temporarily,
and I'm asking what you envision about that.

What's a use case for doing that, and how do you see someone
doing it (other than by hitting a key bound to d-s-m, for example)?

> My idea was to extend the feature of region activation, which
> would avoid the need for turning on and off the mode.

Why don't you please clarify that idea? What is it that you intend
for users to do, to enable/disable d-s-m "temporarily"? And how
is that different from (how does it "avoid") temporarily turning the
mode on/off?

Maybe I'm the only one who finds your proposal vague. I posted
my questions about it only after it seemed that Yuri had the same,
or similar questions. If you want me to understand - and I would
like to, please try to elaborate.

Re: delete-selection-mode as default

[Eli Zaretskii]

> Date: Tue, 18 Sep 2018 10:42:21 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: yurivkhan@gmail.com, hw@adminart.net, spacibba@aol.com,
>         joostkremers@fastmail.fm, npostavs@gmail.com, emacs-devel@gnu.org,
>         acm@muc.de, phillip.lord@russet.org.uk
> 
> > > What's the real use case for such temporary enabling/disabling of d-s-m?
> > > And how is it different from just, well, enabling/disabling d-s-m?
> > 
> > People who are against turning on delete-selection-mode presented
> > several such use cases.
> 
> I don't think so. I think you just postulated it, without any example.
> Did someone who is against using d-s-m actually say that s?he
> wanted to use it temporarily (and without turning d-s-m on,
> whatever that means)?
> 
> But I could be wrong - it's a long thread. Feel free to point us to
> some mention by someone of such a use case. Or if that's not
> possible, please remind us of (describe) such a case.

Look for messages from Alan and Richard.  I cannot afford searching
for them, life is too short.

> > > In any case, how do you envision enabling/disabling d-s-m as something
> > > different from turning d-s-m on/off? If you want some key(s) to
> > > enable/disable it, how is that different from just binding a key 
> > > (or keys) to `delete-selection-mode'?
> > 
> > Why don't you ask the same question about transient-mark-mode?
> 
> Why do you think I should do that?

Because in that case we have a few commands that temporarily turn on
transient-mark-mode.  We don't tell users to turn it on and off
explicitly.  I thought it might be a good idea to have a similar
feature for delete-selection-mode.

> What's a use case for doing that, and how do you see someone
> doing it (other than by hitting a key bound to d-s-m, for example)?

See above: asked and answered.

> > My idea was to extend the feature of region activation, which
> > would avoid the need for turning on and off the mode.
> 
> Why don't you please clarify that idea? What is it that you intend
> for users to do, to enable/disable d-s-m "temporarily"?

Something similar to what we do for turning on transient-mark-mode
temporarily.

> Maybe I'm the only one who finds your proposal vague. I posted
> my questions about it only after it seemed that Yuri had the same,
> or similar questions. If you want me to understand - and I would
> like to, please try to elaborate.

I explained the idea in so many words several times already.  If it's
still not clear, I guess I will have to give up.

Re: delete-selection-mode as default

[Alan Mackenzie]

Hello, Eli and Drew.

On Tue, Sep 18, 2018 at 21:30:28 +0300, Eli Zaretskii wrote:
> > Date: Tue, 18 Sep 2018 10:42:21 -0700 (PDT)
> > From: Drew Adams <drew.adams@oracle.com>
> > Cc: yurivkhan@gmail.com, hw@adminart.net, spacibba@aol.com,
> >         joostkremers@fastmail.fm, npostavs@gmail.com, emacs-devel@gnu.org,
> >         acm@muc.de, phillip.lord@russet.org.uk

> > > > What's the real use case for such temporary enabling/disabling of d-s-m?
> > > > And how is it different from just, well, enabling/disabling d-s-m?

> > > People who are against turning on delete-selection-mode presented
> > > several such use cases.

> > I don't think so. I think you just postulated it, without any example.
> > Did someone who is against using d-s-m actually say that s?he
> > wanted to use it temporarily (and without turning d-s-m on,
> > whatever that means)?

> > But I could be wrong - it's a long thread. Feel free to point us to
> > some mention by someone of such a use case. Or if that's not
> > possible, please remind us of (describe) such a case.

> Look for messages from Alan and Richard.  I cannot afford searching
> for them, life is too short.

I think you mean the following reply to me, which I quote in full for
Drew's benefit:

*************************************************************************
Date: Sat, 15 Sep 2018 13:56:27 +0300
From: Eli Zaretskii <eliz@gnu.org>
To: Alan Mackenzie <acm@muc.de>
CC: drew.adams@oracle.com, yurivkhan@gmail.com, hw@adminart.net,
spacibba@aol.com, joostkremers@fastmail.fm, npostavs@gmail.com,
emacs-devel@gnu.org, phillip.lord@russet.org.uk
Subject: Re: delete-selection-mode as default
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x
[generic]
X-Received-From: 2001:4830:134:3::e

> Date: Sat, 15 Sep 2018 10:20:16 +0000
> Cc: Drew Adams <drew.adams@oracle.com>, yurivkhan@gmail.com,
> hw@adminart.net,
>   spacibba@aol.com, joostkremers@fastmail.fm, npostavs@gmail.com,
>   emacs-devel@gnu.org, phillip.lord@russet.org.uk
> From: Alan Mackenzie <acm@muc.de>
>
> I can't help feeling that this isn't the right approach.  I feel that
> it
> will increase complexity which the new features won't justify.  I know
> I'm speaking as an "extremist" (i.e. no transient-mark-mode at all)
> here,
> but still: I think having to press a key sequence before d-s-m would
> work
> would take the purpose of d-s-m away - that key sequence might as well
> be
> C-w.

People who want delete-selection-mode enabled by default won't need to
type that additional key, because for them the region will already
have the correct state.  delete-selection-mode will take care of that.

It is those who do NO want delete-selection-mode turned on by default,
people like you and me, who will be ABLE to use delete-selection-mode
by typing an extra key.  Those users will also be capable of
"activating" and "deactivating" the region like transient-mark-mode
does with a single command, thus allowing them to invoke commands that
act on an "active" region without turning on transient-mark-mode
globally.

> You seem to be proposing to associate a three-value state with the
> region, which state users could change with key sequences.  I can see
> this being more confusing than the current two-value state (or is it
> 2.5?) we currently have.

It cannot be more confusing, because for those who already turn on
transient-mark-mode and/or delete-selection-mode it leaves the matters
exactly like they are.  It actually should _improve_ on that by
letting those users temporarily turn on/off those modes for the
purposes of processing a given region by one or more commands.

> It might well be that, having introduced transient-mark-mode as a
> default, a certain degree of confusion in Emacs is unavoidable.  If so,
> does it make sense to spend a lot of effort which might merely switch
> the
> confusion to somewhere else?  Assuming that we'd want to have options
> to
> retain all the "old" behaviour, I think it would be difficult to avoid
> increasing the confusion.

I hope you will now reconsider this remark.

> I've interacted somewhat with hw, who's been driving this thread, and
> come to the conclusion that he doesn't really want to use Emacs.

That's irrelevant for the purposes of my proposal.  I do want to use
Emacs, and so I hope do you.
*************************************************************************

And yes, Eli, I do want to use Emacs, very much so!

I remain genuinely sceptical about the ideas for en/disabling
delete-selection-mode.  I'm convinced neither that they're a good idea,
nor a bad idea.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: delete-selection-mode as default

[Elias Mårtenson]

[-- Attachment #1: Type: text/plain, Size: 1619 bytes --]

On Fri, 14 Sep 2018 at 21:43, Yuri Khan <yurivkhan@gmail.com> wrote:


> One other thing that I want is that the region be highlighted if and
> only if it is going to be the target of the next command I give,
> because I like to look before I leap. It seems transient-mark-mode is
> intended to give me this by adding the concept of active region and
> highlighting the region when it is active. However, many commands act
> on the region even if it is inactive. kill-region and
> copy-region-as-kill are two such commands. I am sure there are many
> more, because it is much easier to write:
>
> (defun my-command (BEGIN END)
>   (interactive "r")
>   ;; do something between BEGIN and END
> )
>
> than:
>
> (defun my-command (BEGIN END)
>   (interactive (if (use-region-p)
>                    (list (min (point) (mark)) (max (point) (mark)))
>                  ;; figure out what to do when no region is active
>                  ;; * act on the whole buffer
>                  ;; * act on the current narrowing
>                  ;; * signal an error
>                  ;; * do something else sensible
>                  (list ?? ??)))
>   ;; do something between BEGIN and END
> )
>

I've seen functions implemented like that, and I would consider those
buggy. It's going directly against the concept of the point and mark as
being the region. I know some people want the same behaviour as gedit or
whatever editor is default in desktop environments these days, but the
Emacs way really is powerful and it would be useful if people who want to
change things at least understood this concept first.

Regards,
Elias

[-- Attachment #2: Type: text/html, Size: 2094 bytes --]

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.

Re: delete-selection-mode as default

[hw]

Drew Adams <drew.adams@oracle.com> writes:

> [...]
> 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.

I know it's intended to be the way.  Yet having a hidden region all the
time always made me feel uneasy because it *is* dangerous to have a part
of the buffer --- the extent of which is not really known and changes
with every movement of point --- being always subject to commands that
may delete it or do whatever with it when I happen to make a mistake.
And I might not even realize having made the mistake because it all
happens hidden.

I remember when I learned about it, I immediately decided it's a very
bad and dangerous thing to have and did my best to avoid it.  So over
the decades, I've become good at ignoring this stupid region thing and
at not making mistakes that accidentally modify regions.

That doesn't mean lurking hidden regions waiting for my mistakes are
good, and it doesn't matter if that was the intended way.  Not all of
Emacs` ways are perfect, and this is a way I'd really like to see
finally change.

> It's a perfectly fine, efficient, and logical behavior.

not to me

And with evolutions like t-m-m and d-s-m it seems to have become more
inconsistent, confusing and way too complicated.

> [...]
> 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.

Maybe it can happen once this mess has been cleaned up.

> 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.
> [...]

right

an article and a tutorial

Re: delete-selection-mode as default

[hw]

Alan Mackenzie <acm@muc.de> writes:


> [...]
>> >> Then how come I can't even see where the mark is, let alone the region?
>> >> Why is that not displayed?
>
>> > Because this was tried and found counter-productive.
>
>> It would be very helpful and not counter productive at all.
>
> Please, I'm am telling you what others found by experience.

So transient-mark-mode is counter productive --- strange that it did
become the default.  Unfortunately, it wasn't implemented with
consistency and not all the way through.

>> >> When highlighting screws up your syntax highlighting, maybe a different
>> >> way of highlighting could help.  Even only marking the fringes of lines
>> >> that are selected would be better than nothing.
>
>> > I prefer nothing, thanks.  Would you want to make my preferred way of
>> > working impossible?
>
>> No, it only doesn't make any sense to pretend that there is a selection
>> when there is actually none.
>
> 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.

It makes perfect sense, and it's how I'm using Emacs.  What doesn't make
sense is these hidden regions, the impossibility of making a
navigational aid visible, the ability to do stuff with selections
without them being selected and the messing up of navigational things
with making selections.

> 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.

So you see how the concept of regions doesn't make sense and could use
an overhaul.

>> It gets even worse when Emacs pretends that there is a selection when
>> there is actually none only because the user once had to set a mark
>> somewhere to make a selection and would have to kill the whole buffer
>> to get rid of the mark and thus the pretended selection.
>
> In Emacs there is the region, as I said.

Pretending, or just assuming, that there is a selection when there is
none is a bad idea.

Imagine I select a line, copy it, move to another place and paste it.
Emacs assumes that there is a selection I can do stuff with, like
copying and deleting or narrowing the buffer to it.  If I make a mistake
and press the wrong key, Emacs acts on this assumption and messes up my
file.  That's a design flaw.  This isn't useful for navigation, either,
because when I yank, Emacs randomly sets the mark somewhere else.  So if
I wanted to go back to from where I copied the line, I'd be better off
to have set a bookmark or a register first.  I could press C-x C-x and
get the copy of the line I just created selected, and that's useless
because I already copied that line.

This pretending/assuming is not useful for anything but making mistakes
worse.

> [...]
>
>> >> > There are many advantages to having transient-mark-mode disabled:
>> >> > primarily simplicity, and the severe reduction in the modal
>> >> > behaviour (in the sense of key sequences doing different things in
>> >> > things like vi's insert mode and command mode).  And I'm not happy
>> >> > having my font-locking splatted by the region's highlighting.
>
>> >> Any simplicity here is no more than a deceptive apparition.
>
>> > :-)  No, the simplicity is real.
>
>> There is no simplicity.
>
> I'm telling you my experience, I'm not making things up.  Why do you
> think I disable transient-mark-mode in my Emacs, then?

I think it's because you dislike any other highlighting than what you
already have so badly that you make things hard for yourself by not
being able to see what you have selected and by forcing yourself to
having to go to lengths when you need to limit functions to a selection.

I don't understand why you need to read the part you have selected for
the few seconds it takes to do something with it in perfect
highlighting.  You could simply read it first and then select it.  You
don't need to read it while you make a selection, but you could finally
see what you're working with.

> [ .... ]
>
>> None of the options would do what I want, and making an extension that
>> does what I want isn't really an option, either.
>
> Enabling transient-mark-mode and setting mark-even-if-inactive to nil
> gives you what you've said you want, I think.

Partly --- it still doesn't decouple the mark from making selections so
it could be used for navigation.

What it seems to do is to require the selection to be highlighted when
you want to do something with it.  It's description is a bit weird:

,----
| Non-nil means you can use the mark even when inactive.
| This option makes a difference in Transient Mark mode.
| When the option is non-nil, deactivation of the mark
| turns off region highlighting, but commands that use the mark
| behave as if the mark were still active.
`----

What does 'using the mark' refer to?  I'm not using the mark, it's for
navigation and can not be used for that while it is broken by being
coupled to making selections.

The description doesn't say what it means when mark-even-if-inactive is
nil, and the 3rd sentence kinda repeats what the first one said, but it
doesn't seem to be true.  Query-replace definitely doesn't behave as if
the region were still active when mark-even-if-inactive is non-nil.

Maybe this is better:

,----
| This option makes a difference in Transient Mark mode.  When the value
| is nil, doing something with a hidden region is not possible.  When
| the option is non-nil, commands that do something with a hidden region
| work as if transient-mark-mode was disabled.
`----

I don't know what effect it has on active regions and what it does when
transient mark mode is disabled, though.

>> Again, this stuff needs an overhaul.
>
> I don't think you've managed to persuade anybody, certainly not me (yet).

Well, you got an example above with mark-even-if-inactive:  What does it
actually mean, and how is all this supposed to make sense?

What sense does it make that mark-even-if-inactive is non-nil by default
with transient-mark-mode enabled being the default?  It should be nil by
default because that would make a lot more sense.

> Why are you using Emacs at all?  You seem to dislike its core concepts
> and methods fairly strongly.

That some things don't make sense doesn't mean I dislike Emacs.  I like
it very much, and I think it might be good if it had more users, so I'm
pointing out what doesn't make sense so things can be improved upon.

It was suggested to make delete-selection-mode the default because it
seems likely that new users might expect the behaviour it provides.  I'm
going a bit further by saying that making and working with selections
could use an overhaul because there are so many inconsistent things
involved and that it all doesn't make much sense once you start thinking
about it --- and before that is sorted out, changing the default to be
d-s-m enabled doesn't seem a good idea.

> There are other editors available, some of which will more closely
> approximate the way you want to handle selections.  Why are you
> sticking with Emacs?

Which one would be a better alternative?

Re: delete-selection-mode as default

[Juri Linkov]

> But we should also offer a command that just activates the region,
> nothing more. By default that would be unbound (or at most bound
> to something other than `C-x C-x').

This is an interesting idea.  Often there is need to type C-x four(!) times:
first `C-x C-x' to activate the region, and another `C-x C-x' to put point
back where it was before previous swapping point and mark with `C-x C-x'
because some commands expect point to be at certain boundary of the region,
like query-replace operating on the region with the initial position
at the region beginning.

So perhaps `activate-mark' should be a command, preferably
bound to some easy to type key like `C-x C-SPC'.

> `C-x C-x' bound to a command that just swaps point and mark
> without activating the region

`C-u C-x C-x' swaps point and mark without activating the region,
so a new customizable option could invert the meaning of its prefix arg,
and its default value could depend of whether d-s-m is active.

RE: delete-selection-mode as default

[Drew Adams]

> > But we should also offer a command that just activates the region,
> > nothing more. By default that would be unbound (or at most bound
> > to something other than `C-x C-x').
> 
> This is an interesting idea.  Often there is need to type C-x four(!) times:
> first `C-x C-x' to activate the region, and another `C-x C-x' to put point
> back where it was before previous swapping point and mark with `C-x C-x'
> because some commands expect point to be at certain boundary of the region,
> like query-replace operating on the region with the initial position
> at the region beginning.
> 
> So perhaps `activate-mark' should be a command, preferably
> bound to some easy to type key like `C-x C-SPC'.

That's taken by `pop-global-mark'. And users who have rebound it
might well have rebound it to some similar action. Icicles binds it
by default to ` icicle-goto-global-marker-or-pop-global-mark', which
lets you navigate among local or global markers.

Let's just have the command first, without binding it to a key.

> > `C-x C-x' bound to a command that just swaps point and mark
> > without activating the region
> 
> `C-u C-x C-x' swaps point and mark without activating the region,
> so a new customizable option could invert the meaning of its prefix arg,
> and its default value could depend of whether d-s-m is active.

Again, users who have rebound it might well have rebound it to some
similar action. Icicles puts several alternative behaviors on `C-x C-x':

  'exchange-point-and-mark' or save a region or select a saved region.
  With no prefix arg, invoke 'exchange-point-and-mark'.
  If you use library 'Bookmark+', then you can use a prefix arg.

   * Plain 'C-u': What vanilla Emacs does - temporary Transient Mark mode.
   * Plain 'C-u C-u': select (activate) one or more bookmarked regions.
   * Numeric prefix arg: bookmark (save) the active region using
     'icicle-bookmark-cmd'.

     . Arg < 0: Prompt for the bookmark name.
     . Arg > 0: Do not prompt for the bookmark name.  Use the buffer name
                plus a prefix of the region text as the bookmark name.
     . Arg = 0: Same as > 0, except do not overwrite any existing bookmark
                with the same name.

Re: delete-selection-mode as default (WAS: Some developement questions)

[Eli Zaretskii]

> From: Joost Kremers <joostkremers@fastmail.fm>
> Cc: Noam Postavsky <npostavs@gmail.com>, hw@adminart.net, spacibba@aol.com, phillip.lord@russet.org.uk, drew.adams@oracle.com, emacs-devel@gnu.org
> Date: Sun, 09 Sep 2018 22:39:54 +0200
> 
> what `delete-selection-mode` does is standard behaviour in most
> software out there and most new users will take it for granted

The _only_ problem I personally have with delete-selection-mode is
that it also replaces the region created by the likes of "C-x C-x",
something that "most software out there" does not and cannot do.  If
we were to change delete-selection-mode to replace only highlighted
text created by mouse selections or by shift-selections, I think we
could then enable it by default without much resistance, because
typing a character or DEL after explicitly selecting text is many
orders of magnitude less probable to be a mistake than when we make
the region active by other means.

I suspect that making the above happen would need to introduce a
special kind of region, though.  But if we want to present a UI and
provide a UX similar to other editors, I don't see any other way.  I
think the conclusion from the transient-mark-mode experiment is that
it is not up to the job we hoped it will do, due to conflicting
requirements that cannot be reconciled by reasonably reliable
heuristics.  The traditional Emacs region cannot support
delete-selection-mode and its traditional uses at the same time.

Re: delete-selection-mode as default

[Stefan Monnier]

> The _only_ problem I personally have with delete-selection-mode is
> that it also replaces the region created by the likes of "C-x C-x",
> something that "most software out there" does not and cannot do.

AFAIU the issue here is that you're using C-x C-x as navigation (a habit
you might have gotten from the time when transient-mark-mode was
disabled) rather than as a way to activate the region.

So I think this is a not a problem with d-s-m but with C-x C-x.

Also, I think it's a problem that comes from your habits, and if d-s-m
had always been enabled you'd simply have different habits and wouldn't
suffer from it.

So I'm not sure it's an argument against d-s-m, really.


        Stefan

Re: delete-selection-mode as default

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 10 Sep 2018 09:41:20 -0400
> 
> > The _only_ problem I personally have with delete-selection-mode is
> > that it also replaces the region created by the likes of "C-x C-x",
> > something that "most software out there" does not and cannot do.
> 
> AFAIU the issue here is that you're using C-x C-x as navigation (a habit
> you might have gotten from the time when transient-mark-mode was
> disabled) rather than as a way to activate the region.
> 
> So I think this is a not a problem with d-s-m but with C-x C-x.
> 
> Also, I think it's a problem that comes from your habits, and if d-s-m
> had always been enabled you'd simply have different habits and wouldn't
> suffer from it.

A lot of Emacs commands put a mark before moving "far away" (for some
value of "far"), the reason being that the user might want to return
there.  What would you suggest as a "different habit" for returning to
that previous place, instead of "C-x C-x"?

And, btw, I find nothing wring with this habit of mine, the only
problem here is that someone decided that "C-x C-x" should activate
the region.

> So I'm not sure it's an argument against d-s-m, really.

Indeed, it could be an argument against "C-x C-x" and/or
transient-mark-mode, except that "C-x C-x" was there first.

Re: delete-selection-mode as default

[Stefan Monnier]

> A lot of Emacs commands put a mark before moving "far away" (for some
> value of "far"), the reason being that the user might want to return
> there.  What would you suggest as a "different habit" for returning to
> that previous place, instead of "C-x C-x"?
> And, btw, I find nothing wrong with this habit of mine, the only
> problem here is that someone decided that "C-x C-x" should activate
> the region.

I don't find anything wrong with it either, but C-x C-x doesn't serve
you well currently for this reason (this is a problem that affects more
than d-s-m).  It does two different (tho related) things, and for some
users this isn't right.

For use-cases like yours, you'd probably be better served by swapping
the behavior of `C-x C-x` and `C-u C-x C-x` (i.e. make it so `C-x C-x`
only activates the region if you specifically ask for it with C-u).

Or split the two into two separate commands:
- one to exchange mark and point.
- another to (re)activate the region.

>> So I'm not sure it's an argument against d-s-m, really.
> Indeed, it could be an argument against "C-x C-x" and/or
> transient-mark-mode, except that "C-x C-x" was there first.

Exactly,


        Stefan

RE: delete-selection-mode as default

[Drew Adams]

> > The _only_ problem I personally have with delete-selection-mode is
> > that it also replaces the region created by the likes of "C-x C-x",
> > something that "most software out there" does not and cannot do.
> 
> AFAIU the issue here is that you're using C-x C-x as navigation (a habit
> you might have gotten from the time when transient-mark-mode was
> disabled) rather than as a way to activate the region.
> 
> So I think this is a not a problem with d-s-m but with C-x C-x.

Exactly a point that I made too.

From the moment that we introduced the notion of an "active"
region (i.e. introduced `transient-mark-mode') the fact that a
region is active means, in effect, that you expect to (because
you are able to) do something with it.

That's not necessarily the case for all uses of `C-x C-x'. When
it's not the case, you can use `C-g' to deactivate it. And that's
what you would (have to) do if `d-s-m' is enabled and you do
not want to act on it (e.g. delete/replace it).

If the annoyance for `d-s-m' for a particular user comes only
from `C-x C-x' then a solution (for that user) is to have an
equivalent of `C-x C-x' that does not activate (or that then
deactivates) the region.

> Also, I think it's a problem that comes from your habits, and if d-s-m
> had always been enabled you'd simply have different habits and wouldn't
> suffer from it.
> 
> So I'm not sure it's an argument against d-s-m, really.

RE: delete-selection-mode as default

[Drew Adams]

> And, btw, I find nothing wring with this habit of mine, the only
> problem here is that someone decided that "C-x C-x" should activate
> the region.

Yes. `transient-mark-mode' does it.

Consider a replacement for `C-x C-x' that does not activate
the region. And a command to only activate it (without
swapping point and mark), so you can still activate it on
demand.

Coupling swapping point and mark with activating the
region - as the only way to do the former - was probably
a mistake.

It's OK to provide a command that couples the two, for
convenience for those folks (most of us?) who want that.
But perhaps we should now consider having two different
commands (plus the convenience combo).

> > So I'm not sure it's an argument against d-s-m, really.
> 
> Indeed, it could be an argument against "C-x C-x" and/or
> transient-mark-mode, except that "C-x C-x" was there first.

Yes.

Re: delete-selection-mode as default

[Eli Zaretskii]

> Date: Mon, 10 Sep 2018 07:30:08 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: emacs-devel@gnu.org
> 
> > And, btw, I find nothing wring with this habit of mine, the only
> > problem here is that someone decided that "C-x C-x" should activate
> > the region.
> 
> Yes. `transient-mark-mode' does it.
> 
> Consider a replacement for `C-x C-x' that does not activate
> the region.

If you mean for everybody (i.e. by default), then I'd welcome patches
to that effect, and maybe that would be a first step towards making
delete-selection-mode on by default without annoying veteran Emacs
users who are fast typist.

If you mean for my own use, then it should be clear to you that my own
problems with this were solved long ago by my customizations.  All
this thread is not about my usability problem, it's about everyone
else.

Re: delete-selection-mode as default

[Yuri Khan]

On Mon, Sep 10, 2018 at 9:34 PM Drew Adams <drew.adams@oracle.com> wrote:

> Consider a replacement for `C-x C-x' that does not activate
> the region.

FWIW, with cua-mode active:

===
C-x C-x runs the command cua-exchange-point-and-mark (found in
cua-global-keymap), which is an interactive compiled Lisp function in
‘cua-base.el’.

It is bound to C-x C-x.

(cua-exchange-point-and-mark ARG)

Exchange point and mark.
Don’t activate the mark if ‘cua-enable-cua-keys’ is non-nil.
Otherwise, just activate the mark if a prefix ARG is given.

See also ‘exchange-point-and-mark’.
===

RE: delete-selection-mode as default

[Drew Adams]

> > > And, btw, I find nothing wring with this habit of mine, the only
> > > problem here is that someone decided that "C-x C-x" should activate
> > > the region.
> >
> > Yes. `transient-mark-mode' does it.
> >
> > Consider a replacement for `C-x C-x' that does not activate
> > the region.
> 
> If you mean for everybody (i.e. by default), then I'd welcome patches
> to that effect, and maybe that would be a first step towards making
> delete-selection-mode on by default without annoying veteran Emacs
> users who are fast typist.

I meant that it might help for Emacs to provide such things.

I think that we should have decoupled point-mark swapping
from region activation from the beginning, but we should
also have provided a command that combines them (instead
of only the latter, as `C-x C-x').

Personally, I'd like to see both d-s-m turned on by default
and `C-x C-x' bound to a command that does what it does
now (activates and swaps).

But users should be able to choose: (1) not to use d-s-m,
(2) to swap point and mark without activating the region.

If d-s-m is not on by default, then the question is whether
to change the default behavior of `C-x C-x'.

I don't have an opinion about that, but maybe we shouldn't
change it at this point. If we don't turn on d-s-m then it
should be enough to provide the decoupling. But if long-time
users who dislike d-s-m don't actually take advantage of the
decoupling then that might not really ease the way toward a
possible future enabling of d-s-m by  default.

> If you mean for my own use, then it should be clear to you that my own
> problems with this were solved long ago by my customizations.  All
> this thread is not about my usability problem, it's about everyone
> else.

Right; this discussion not particularly about your use or my use.

Re: delete-selection-mode as default (WAS: Some developement questions)

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > The _only_ problem I personally have with delete-selection-mode is
  > that it also replaces the region created by the likes of "C-x C-x",
  > something that "most software out there" does not and cannot do.

I agree.  What I want to happen after I make a region with ordinary
Emacs commands, including C-SPC M-f and C-x C-x, is this:

  * It is active.
  * It is highlighted.
  * DEL does not delete it.
  * self-insert does not delete it.

However, marking a region with the mouse is a different case.  If DEL
and self-insert were to delete such a region, I would not object.

As for shift selection, that uses keyboard commands, so I think it is
natural to treat them like other keyboard commands in this regard.
But I don't use shift selection, so I would be inclined to follow the
preferences of users that really do use shift selection.  I'd create
a separate setting to control this case, then set the default based on
their preferences.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: delete-selection-mode as default

[Stefan Monnier]

> I agree.  What I want to happen after I make a region with ordinary
> Emacs commands, including C-SPC M-f and C-x C-x, is this:
>
>   * It is active.
>   * It is highlighted.
>   * DEL does not delete it.
>   * self-insert does not delete it.

DEL has been deleting the active region (in the default config) for
a while now.  And I'm pretty happy about that because it saves me
a key-binding.  I think it's just as useful as confining undo and
search&replace to the active region: the active region is an extra
argument to the command.  It makes the active region into something
comparable to the C-u prefix, a general way to structure the space of
our commands.  VI has even more structure, and I wish Emacs moved more
in this direction.


        Stefan

Re: delete-selection-mode as default

[hw]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I agree.  What I want to happen after I make a region with ordinary
>> Emacs commands, including C-SPC M-f and C-x C-x, is this:
>>
>>   * It is active.
>>   * It is highlighted.
>>   * DEL does not delete it.
>>   * self-insert does not delete it.
>
> DEL has been deleting the active region (in the default config) for
> a while now.  And I'm pretty happy about that because it saves me
> a key-binding.  I think it's just as useful as confining undo and
> search&replace to the active region: the active region is an extra
> argument to the command.  It makes the active region into something
> comparable to the C-u prefix, a general way to structure the space of
> our commands.  VI has even more structure, and I wish Emacs moved more
> in this direction.

Aren't users going to need to set preferences as to what shall be
limited or extended in which way to or by an highlighted region when
more and more things fall under the paradigm of "doing something with a
region just because it is highlighted and thus to be considered more
active than when it is not"?

Delete-selection-mode may count as an example of such a preference; a
user not liking undo restricted to a region may be another.  The next
one might not like it that a non-highlighted region can be copied and
deleted and abused for navigation and would rather have it entirely
inert than only not so active.

At least I would separate between "highlighted" and "active" first and
go from there.  Otherwise users who don't like this paradigm still won't
be able to see what they have selected, and others can't see what they
have selected unless they want to do something with it, or abort wanting
to do something with it as soon as they've seen it.

Re: delete-selection-mode as default

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > DEL has been deleting the active region (in the default config) for
  > a while now.

It affects me only by screwing me.  It means, for instance, that after
a search I can't edit what I searched for in the natural way.


-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: delete-selection-mode as default

[Stefan Monnier]

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > DEL has been deleting the active region (in the default config) for
>   > a while now.
>
> It affects me only by screwing me.  It means, for instance, that after
> a search I can't edit what I searched for in the natural way.

Not sure I understand how the active region relates to what you can do
after a search.


        Stefan

Re: delete-selection-mode as default

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Not sure I understand how the active region relates to what you can do
  > after a search.

This is strange.  I have a clear memory that search activated the region
around the string that was found -- but it doesn't do that now.

Was that behavior in effect before?

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

RE: delete-selection-mode as default

[Drew Adams]

> > Users can trivially control which of the 5 behaviors to use for
> > a given command, just by putting a property on the command
> > symbol.
> 
> Putting properties on symbols to change the behavior of a command is
> not user-level customization.  IOW, we are miscommunicating.

There are users, and there are users. I didn't say that users
will do that in general. Far from it.

I don't know anyone who has ever bothered to set the d-s-m
behavior for a particular command, unless it's a new command
that they themselves created.

That's the typical use case: causing your own command that's
similar to standard `yank' or `backward-delete-char-untabify'
or... to behave like the standard command wrt d-s-m.

If you create a yank command then you want d-s-m to treat it
as such (not to yank back the text that it just deleted). Typically
this is done for a library, but it could be done in a user init file.

The point is that you can, if you need/want to, _trivially_
define the specific behavior for a given command. Nothing
complicated for any user to do that, even if very few will ever
need to.

> > There's no difficulty "reconciling" d-s-m with the "other
> > uses" of the region that you cite. None whatsoever.
> > You've shown none, AFAICT. No trick is needed. It just
> > works.
> 
> This whole thread makes it acutely clear that there is a problem.

I disagree that there is a problem with d-s-m, or with
turning it on by default. You tout irreconcilability but give
no example.

It's true that problems have been cited in the thread:

   Misunderstandings come from mistaken expectations and
   the fact that different users use Emacs differently.

   Confusion can come from the fact that there are multiple
   knobs to control region behavior (and not just two modes,
   t-m-m and d-s-m), and it's not obvious sometimes that a
   given knob exists or how the various knobs interact.

That users can be confused about the region etc. does not
stem from d-s-m - please don't scapegoat it.

Confusion comes primarily from the introduction of
t-m-m and, especially, the coupling, in C-x C-x, of region
activation with swapping point and mark. There was no
confusion before that. And no confusion was introduced
by adding d-s-m.

The fact that users who might want to really understand
all of the various possibilities need to scour the manual
to find info that is spread all over the place is too bad.
I mentioned some possibilities for helping with that.

But normally a given user just knows what s?he uses,
and doesn't try to know about and understand every
possibility regarding point, mark, region, selection,
activation, highlighting, action, deletion, etc.

This discussion, since it now deals with all possibilities
(because people who take different approaches have
widened the scope), has made apparent the complications.

But a given user normally doesn't sense how complicated
this stuff can be. Mr X knows his way of using the region;
Ms Y knows her way, and so on.

> And your message actually agrees with me towards the end.

Again, I disagree. Do you mean the text cited just above?
If not, where do you think I've agreed with you that there's
inherent difficulty "reconciling" d-s-m with the "other uses"
of the region that you cite?

You make it sound like things are crystal clear and simple
with the status quo, and that defaulting to d-s-m would
muddy the waters.

In fact, the waters are muddy now, if one bothers to look
into them. And those umpteen knobs I mentioned do not
come from d-s-m.

You've correctly pointed out that the discussion, e.g.,
between Alan and Hw, ranging to `mark-even-if-inactive'
and beyond, has pointed out complications. What's not
correct is to suggest that the complications come from d-s-m.

It's wrong to suggest that all is harmonious between
your first two region "uses": navigation and invoking
commands on a region, and that your third "use",
delete-selection-mode, is the irreconcilable culprit that
threatens to spit in the soup and turn harmony into discord.

Defaulting to d-s-m would just make life simpler for
most users (IMHO). And those who don't want d-s-m
on can turn it off.

And whether it is on or off, or whether d-s-m even
exists or not, the complications we've pointed out
are present - they don't come from d-s-m mode.

You've decided that d-s-m won't be on by default
anytime soon. OK. But it's wrong to paint a picture
of d-s-m as a bogey man that threatens to sow
contradiction.

Re: delete-selection-mode as default

[Eli Zaretskii]

> Date: Fri, 14 Sep 2018 13:57:59 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: yurivkhan@gmail.com, acm@muc.de, hw@adminart.net, spacibba@aol.com,
>         joostkremers@fastmail.fm, npostavs@gmail.com, emacs-devel@gnu.org,
>         phillip.lord@russet.org.uk
> 
> > > Users can trivially control which of the 5 behaviors to use for
> > > a given command, just by putting a property on the command
> > > symbol.
> > 
> > Putting properties on symbols to change the behavior of a command is
> > not user-level customization.  IOW, we are miscommunicating.
> 
> There are users, and there are users. I didn't say that users
> will do that in general. Far from it.
> 
> I don't know anyone who has ever bothered to set the d-s-m
> behavior for a particular command, unless it's a new command
> that they themselves created.

Fine, then we agree.  The above issue is not relevant to what I
perceive as the main problem here: how to give us a way to allow
turning on delete-selection-mode without alienating users who have no
use for it and very much dislike its effects, in particular when those
effects are unintended.

> I disagree that there is a problem with d-s-m, or with
> turning it on by default. You tout irreconcilability but give
> no example.

There are plenty of examples in this thread, I see no need to repeat
them.

> That users can be confused about the region etc. does not
> stem from d-s-m - please don't scapegoat it.
> 
> Confusion comes primarily from the introduction of
> t-m-m and, especially, the coupling, in C-x C-x, of region
> activation with swapping point and mark. There was no
> confusion before that. And no confusion was introduced
> by adding d-s-m.

I didn't "scapegoat" anything.  It is immaterial which of the 3 uses
of the region is "to blame", because this is not about assigning
blame.  My description was following the time line: the other 2 uses
of the region are already turned on by default, whereas
delete-selection-mode is not.  It doesn't mean delete-selection-mode
is somehow "guilty".

> But normally a given user just knows what s?he uses,
> and doesn't try to know about and understand every
> possibility regarding point, mark, region, selection,
> activation, highlighting, action, deletion, etc.

My point is that even users who know what they are doing currently
have no good means to tell that to Emacs on a case by case basis.  If
they turn on transient-mark-mode, they get a whole slew of non-trivial
behaviors as a single package deal; if they turn on
delete-selection-mode, they have another package deal which
contradicts some of the one they get with transient-mark-mode.

My proposal is to give users a more fine-grained control of that, so
that users could control the "meaning" of the current region with
easily typed commands, and by that tell the next command(s) how to
interpret the region.  The implementation of this proposal could be
based on a new "state" of the region, which will be the 3rd state in
addition to the currently-available "active" and "inactive" states.
The 3rd state will have the semantics of supporting the behavior
provided by the commands that have the delete-selection property on
their symbols.  Or it could be based on something else.  The important
facet of the proposal is that we need to introduce easily typed
commands that will assign one of the 3 possible meanings to the
current region.

With that, users will have the capability of using delete-selection
features when they need them, without deciding up front that they
prefer those features to other commands that pay attention to active
regions.  We could also teach the commands which could support either
behavior to DTRT by default using some heuristics.  All of this and
more is currently impossible because the same state of the region is
interpreted differently by some commands given a global mode.

> This discussion, since it now deals with all possibilities
> (because people who take different approaches have
> widened the scope), has made apparent the complications.
> 
> But a given user normally doesn't sense how complicated
> this stuff can be. Mr X knows his way of using the region;
> Ms Y knows her way, and so on.

You assume that there's only one "way" for Mr X and Ms Y.  But that
assumption is not necessarily true, for experienced users.  They will
want each of those "ways" in some specific circumstances.  For
example, "C-x C-x" used as navigation tools doesn't need to activate
the region; only the user knows whether that is the case in each
specific use case.  Similarly, typing a character or DEL when the
region is active should replace/delete the region _sometimes_, but not
always, and only the user knows which is which.  As an experienced
user who sometimes needs each one of those features, I would like to
be able to control what happens in each case, and turning on and off
global modes is too blunt an instrument for that; in particular,
the relevant commands are too long and tedious to type.  So I'm
currently forced to choose just one of these 3 features, the one that
gets in my way the least.  I would like to be freed from this "one
fits all use cases" prison.

> You make it sound like things are crystal clear and simple
> with the status quo, and that defaulting to d-s-m would
> muddy the waters.

I said nothing of the kind.  See above.

> In fact, the waters are muddy now, if one bothers to look
> into them.

That's exactly what I'm saying.  I also suggested one way out of this
conundrum.

> What's not correct is to suggest that the complications come from
> d-s-m.

Nothing like that was suggested.  And even if it could be somehow
understood it was, discussing this particular aspect is a tangent that
gets us away from the real issues.  Let's not go there just because we
can.

> It's wrong to suggest that all is harmonious between
> your first two region "uses": navigation and invoking
> commands on a region, and that your third "use",
> delete-selection-mode, is the irreconcilable culprit that
> threatens to spit in the soup and turn harmony into discord.

There's no such suggestion.  Don't feel "offended" on behalf of
delete-selection-mode.  (And there's no need to say the same thing
time and again in so many different ways.)

> Defaulting to d-s-m would just make life simpler for
> most users (IMHO). And those who don't want d-s-m
> on can turn it off.

I believe this is a false dichotomy; there's a better solution that
would leave more users happy.

> You've decided that d-s-m won't be on by default
> anytime soon.

No such decision was made.

Re: delete-selection-mode as default

[Alan Mackenzie]

Hello, Eli.

On Sat, Sep 15, 2018 at 10:50:18 +0300, Eli Zaretskii wrote:
> > Date: Fri, 14 Sep 2018 13:57:59 -0700 (PDT)
> > From: Drew Adams <drew.adams@oracle.com>
> > Cc: yurivkhan@gmail.com, acm@muc.de, hw@adminart.net, spacibba@aol.com,
> >         joostkremers@fastmail.fm, npostavs@gmail.com, emacs-devel@gnu.org,
> >         phillip.lord@russet.org.uk

[ .... ]

> My point is that even users who know what they are doing currently
> have no good means to tell that to Emacs on a case by case basis.  If
> they turn on transient-mark-mode, they get a whole slew of non-trivial
> behaviors as a single package deal; if they turn on
> delete-selection-mode, they have another package deal which
> contradicts some of the one they get with transient-mark-mode.

> My proposal is to give users a more fine-grained control of that, so
> that users could control the "meaning" of the current region with
> easily typed commands, and by that tell the next command(s) how to
> interpret the region.  The implementation of this proposal could be
> based on a new "state" of the region, which will be the 3rd state in
> addition to the currently-available "active" and "inactive" states.
> The 3rd state will have the semantics of supporting the behavior
> provided by the commands that have the delete-selection property on
> their symbols.  Or it could be based on something else.  The important
> facet of the proposal is that we need to introduce easily typed
> commands that will assign one of the 3 possible meanings to the
> current region.

> With that, users will have the capability of using delete-selection
> features when they need them, without deciding up front that they
> prefer those features to other commands that pay attention to active
> regions.  We could also teach the commands which could support either
> behavior to DTRT by default using some heuristics.  All of this and
> more is currently impossible because the same state of the region is
> interpreted differently by some commands given a global mode.

I can't help feeling that this isn't the right approach.  I feel that it
will increase complexity which the new features won't justify.  I know
I'm speaking as an "extremist" (i.e. no transient-mark-mode at all) here,
but still: I think having to press a key sequence before d-s-m would work
would take the purpose of d-s-m away - that key sequence might as well be
C-w.

You seem to be proposing to associate a three-value state with the
region, which state users could change with key sequences.  I can see
this being more confusing than the current two-value state (or is it
2.5?) we currently have.

It might well be that, having introduced transient-mark-mode as a
default, a certain degree of confusion in Emacs is unavoidable.  If so,
does it make sense to spend a lot of effort which might merely switch the
confusion to somewhere else?  Assuming that we'd want to have options to
retain all the "old" behaviour, I think it would be difficult to avoid
increasing the confusion.

I've interacted somewhat with hw, who's been driving this thread, and
come to the conclusion that he doesn't really want to use Emacs.  The
mechanisms of point, mark, and the regions are fundamental to Emacs and
can't be readily customised away.  I don't think we should try to provide
this customisability.

Sorry if I've been a bit negative in this post.

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: delete-selection-mode as default

[Eli Zaretskii]

> Date: Sat, 15 Sep 2018 10:20:16 +0000
> Cc: Drew Adams <drew.adams@oracle.com>, yurivkhan@gmail.com, hw@adminart.net,
>   spacibba@aol.com, joostkremers@fastmail.fm, npostavs@gmail.com,
>   emacs-devel@gnu.org, phillip.lord@russet.org.uk
> From: Alan Mackenzie <acm@muc.de>
> 
> I can't help feeling that this isn't the right approach.  I feel that it
> will increase complexity which the new features won't justify.  I know
> I'm speaking as an "extremist" (i.e. no transient-mark-mode at all) here,
> but still: I think having to press a key sequence before d-s-m would work
> would take the purpose of d-s-m away - that key sequence might as well be
> C-w.

People who want delete-selection-mode enabled by default won't need to
type that additional key, because for them the region will already
have the correct state.  delete-selection-mode will take care of that.

It is those who do NO want delete-selection-mode turned on by default,
people like you and me, who will be ABLE to use delete-selection-mode
by typing an extra key.  Those users will also be capable of
"activating" and "deactivating" the region like transient-mark-mode
does with a single command, thus allowing them to invoke commands that
act on an "active" region without turning on transient-mark-mode
globally.

> You seem to be proposing to associate a three-value state with the
> region, which state users could change with key sequences.  I can see
> this being more confusing than the current two-value state (or is it
> 2.5?) we currently have.

It cannot be more confusing, because for those who already turn on
transient-mark-mode and/or delete-selection-mode it leaves the matters
exactly like they are.  It actually should _improve_ on that by
letting those users temporarily turn on/off those modes for the
purposes of processing a given region by one or more commands.

> It might well be that, having introduced transient-mark-mode as a
> default, a certain degree of confusion in Emacs is unavoidable.  If so,
> does it make sense to spend a lot of effort which might merely switch the
> confusion to somewhere else?  Assuming that we'd want to have options to
> retain all the "old" behaviour, I think it would be difficult to avoid
> increasing the confusion.

I hope you will now reconsider this remark.

> I've interacted somewhat with hw, who's been driving this thread, and
> come to the conclusion that he doesn't really want to use Emacs.

That's irrelevant for the purposes of my proposal.  I do want to use
Emacs, and so I hope do you.

Re: delete-selection-mode as default

[Ergus]

Hi Alan:

On Sat, Sep 15, 2018 at 10:20:16AM +0000, Alan Mackenzie wrote:
>Hello, Eli.
>
>On Sat, Sep 15, 2018 at 10:50:18 +0300, Eli Zaretskii wrote:
>
>I can't help feeling that this isn't the right approach.  I feel that it
>will increase complexity which the new features won't justify.  I know
>I'm speaking as an "extremist" (i.e. no transient-mark-mode at all) here,
>but still: I think having to press a key sequence before d-s-m would work
>would take the purpose of d-s-m away - that key sequence might as well be
>C-w.
>
>You seem to be proposing to associate a three-value state with the
>region, which state users could change with key sequences.  I can see
>this being more confusing than the current two-value state (or is it
>2.5?) we currently have.
>
>It might well be that, having introduced transient-mark-mode as a
>default, a certain degree of confusion in Emacs is unavoidable.  If so,
>does it make sense to spend a lot of effort which might merely switch the
>confusion to somewhere else?  Assuming that we'd want to have options to
>retain all the "old" behaviour, I think it would be difficult to avoid
>increasing the confusion.
>
>I've interacted somewhat with hw, who's been driving this thread, and
>come to the conclusion that he doesn't really want to use Emacs.  The
>mechanisms of point, mark, and the regions are fundamental to Emacs and
>can't be readily customised away.  I don't think we should try to provide
>this customisability.
>
I have also interacted with hw and I totally disagree that he doesn't
want to use emacs. Maybe it is because I am a "younger" emacs users too,
or that I have tried many other editors & IDEs, but I understand what he
says and the fear the first time a user opens emacs comparing to other
similar tools. He just perceives the same than I: Emacs needs changes to
simplify the user experience, but any key change faces too much resistance.

My approach is 

1) To keep the default things AS SIMPLE AS POSSIBLE for the user in any
case, specially in a basic software like a text editor. (SIMPLE and
INTUITIVE if possible)

2) I agree with the Eli's approach to find a mean point that makes
less unhappy most of the people (if possible).

3) But interface changes are needed to survive, they require care to
avoid conflicts and reduce the collapse with backward compatibility, but
are needed.

NEVERTHELESS

The mark-point approach is not a fundamental emacs thing, it is just a
design choice enforced for technical limitations 40 years ago (like the
vi modes, the meta-hyper-syntax and so on) This means that (citing Bill
Joy about vi) it was created for a world that doesn't exist anymore. So
it can (and should) be updated/upgraded as many other things in emacs
and any long living project.

Many emacs default behaviors are confusing for ALL new users even after
reading the tutorial or the manual. Others are just considered as
limitations/bugs because they require too many binds or are very
difficult to find/remember comparing with other editors. But some of
them are design choices made 40, 30 or 20 years ago. New ideas have born
after 1980, different approaches that make the user live easier or were
impossible to try in 1980. But any intent to change the old, becomes in a
thread like this, where many opinions (and very strong ones specially
the ones to keep the status quo) come out and conduce to nothing.

This difficult to change anything in the user interaction makes emacs to
feel still like in 1990 in spite of all the changes and modern stuff if
has. It has open doors to the actual vim use increase, the born and
HUGE grow of editors like atom and sublime and communities like
spacemacs or evil-mode; while the pure emacs use is becoming marginal.

There are new functionalities that appeared more recently and Emacs can
(and should) incorporate asap out of the box (switching lines, selection
highlight, better rectangular selection and interaction). And the real
problem to implement all this is not the emacs potential, but the most
orthodox/purist users that resist too much to any change.

Same thing happens with the suggestions about the tutorial changes, the
proposal of a centralized documentation in a web site and so on.

I think the only way to properly solve this kind of endless discussions
is to ask the users and not only the developers or advanced
users. Something like feathub in the emacs page will work (this should
be extended to many other GNU projects too).

Advantages:

1) Users (new and old) will have a voice in the emacs future.

2) The Developers will know if a proposed functionality will be usefully
for many users and check if it worth to invest time in it (and emacs
code size).

3) Better interaction user-user and user-developer.

4) Developers will know what are the most demanded functionalities with
priorities (easy and fast).

5) Users will have an idea if some functionality will be delivered soon
or not and why, and how many other users claimed them.

6) The featured comments opinions arguments and everything will be
grouped and ordered and if they reborn after some years will be easier
to check if the conditions changed to add it or if

I know that the mailing list can offer all this somehow... but again, it
is something that can be improved. Thinking as a 2018 under 30 yo user.

>Sorry if I've been a bit negative in this post.
>
>[ .... ]
>
>-- 
>Alan Mackenzie (Nuremberg, Germany).

Re: delete-selection-mode as default

[Eli Zaretskii]

> Date: Sat, 15 Sep 2018 21:44:19 +0200
> From: Ergus <spacibba@aol.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, Drew Adams <drew.adams@oracle.com>,
> 	yurivkhan@gmail.com, hw@adminart.net, joostkremers@fastmail.fm,
> 	npostavs@gmail.com, emacs-devel@gnu.org, phillip.lord@russet.org.uk
> 
> The mark-point approach is not a fundamental emacs thing, it is just a
> design choice enforced for technical limitations 40 years ago (like the
> vi modes, the meta-hyper-syntax and so on) This means that (citing Bill
> Joy about vi) it was created for a world that doesn't exist anymore. So
> it can (and should) be updated/upgraded as many other things in emacs
> and any long living project.

I don't agree with you, and in any case it's pointless to try to argue
that using mark and point for navigation in Emacs should go away.  You
will never get this past long-time Emacs users.  We must look for
other ways.

Re: delete-selection-mode as default

[Ergus]

On 15 September 2018 22:01:32 CEST, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Sat, 15 Sep 2018 21:44:19 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>, Drew Adams <drew.adams@oracle.com>,
>> 	yurivkhan@gmail.com, hw@adminart.net, joostkremers@fastmail.fm,
>> 	npostavs@gmail.com, emacs-devel@gnu.org, phillip.lord@russet.org.uk
>> 
>> The mark-point approach is not a fundamental emacs thing, it is just
>a
>> design choice enforced for technical limitations 40 years ago (like
>the
>> vi modes, the meta-hyper-syntax and so on) This means that (citing
>Bill
>> Joy about vi) it was created for a world that doesn't exist anymore.
>So
>> it can (and should) be updated/upgraded as many other things in emacs
>> and any long living project.
>
>I don't agree with you, and in any case it's pointless to try to argue
>that using mark and point for navigation in Emacs should go away.  You
>will never get this past long-time Emacs users.  We must look for
>other ways.

Hi. I never told that it should go away now, or ever. But as many other design choices they could be a solution in a time.   But if it needs changes or a reimplementation (or go away in the future) in favor of something better or new needs, then we shouldn't keep it as is only because a reduced number of people don't want to adapt to the new behaviours.

It should be clear about what is fundamental in emacs behaviour and whats just something that has survived. 

Re: delete-selection-mode as default

[Eli Zaretskii]

> Date: Sun, 16 Sep 2018 02:29:57 +0200
> CC: emacs-devel@gnu.org
> From: Ergus <spacibba@aol.com>
> 
> >I don't agree with you, and in any case it's pointless to try to argue
> >that using mark and point for navigation in Emacs should go away.  You
> >will never get this past long-time Emacs users.  We must look for
> >other ways.
> 
> Hi. I never told that it should go away now, or ever. But as many other design choices they could be a solution in a time.   But if it needs changes or a reimplementation (or go away in the future) in favor of something better or new needs, then we shouldn't keep it as is only because a reduced number of people don't want to adapt to the new behaviours.

See my other message: the fact that region in Emacs serves as basis
for "selections" has deeper roots than just "a reduced number of
people" who use it.

I also question your assessment of the number of people who use the
region in Emacs for features that are beyond what selections can
support.

Re: delete-selection-mode as default

[Alan Mackenzie]

Hello, Ergus.

On Sat, Sep 15, 2018 at 21:44:19 +0200, Ergus wrote:

> I have also interacted with hw and I totally disagree that he doesn't
> want to use emacs. Maybe it is because I am a "younger" emacs users
> too, or that I have tried many other editors & IDEs, but I understand
> what he says and the fear the first time a user opens emacs comparing
> to other similar tools. He just perceives the same than I: Emacs needs
> changes to simplify the user experience, but any key change faces too
> much resistance.

> My approach is 

> 1) To keep the default things AS SIMPLE AS POSSIBLE for the user in
> any case, specially in a basic software like a text editor. (SIMPLE
> and INTUITIVE if possible)

By "simple and intuitive" I think you just mean "like other editors the
user may have already used".  What could be simpler than Emacs's point,
mark and region scheme, and still get the job done?

> 2) I agree with the Eli's approach to find a mean point that makes
> less unhappy most of the people (if possible).

That means, I think, being able to customise Emacs to suit ones' own
preferences.

> 3) But interface changes are needed to survive, they require care to
> avoid conflicts and reduce the collapse with backward compatibility,
> but are needed.

> NEVERTHELESS

> The mark-point approach is not a fundamental emacs thing, it is just a
> design choice enforced for technical limitations 40 years ago (like the
> vi modes, the meta-hyper-syntax and so on) This means that (citing Bill
> Joy about vi) it was created for a world that doesn't exist anymore. So
> it can (and should) be updated/upgraded as many other things in emacs
> and any long living project.

I can't let this pass without comment.  The point, mark, region approach
(I'm considering it here without the complications introduced by
transient-mark-mode) is a stroke of genius, combining austere simplicity
with great flexibility and ease of use.  How well do you understand this
approach?

Just what were these technical limitations which you assert gave rise to
point/mark/region?  The world which gave rise to it may no longer exist,
but the idea is so good that it remains powerful and relevant.
Analogously, the worlds which gave rise to the pottery which
archaeologists dig up are no more, but we still make and use pottery
today.

I fear that by "updated/upgraded" you really mean "made more
complicated, less flexible, and (possibly) dumbed down".

You say "it should be updated/upgraded".  Somebody has to do this work.
Are you prepared to contribute, yourself?  Proposals for changes,
particularly drastic changes, tend to be much better received here when
they come in the form of patches rather than just vague ideas.

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: delete-selection-mode as default

[Alan Mackenzie]

On Sun, Sep 16, 2018 at 17:18:53 +0200, Ergus wrote:


> On 16 September 2018 12:52:25 CEST, Alan Mackenzie <acm@muc.de> wrote:
> >Hello, Ergus.

> >On Sat, Sep 15, 2018 at 21:44:19 +0200, Ergus wrote:

> >> My approach is 

> >> 1) To keep the default things AS SIMPLE AS POSSIBLE for the user in
> >> any case, specially in a basic software like a text editor. (SIMPLE
> >> and INTUITIVE if possible)

> >By "simple and intuitive" I think you just mean "like other editors the
> >user may have already used". 

> There is a reason why all the other editors use similar aproach
> different to this.  So it shouldnt be that bad.

I suggest that reason is to be easily learnable with the minimum of
mental effort.  Emacs's priority is to be as easily usable with the
minimum of effort.  Hence the different approaches.

> >What could be simpler than Emacs's point, mark and region scheme, and
> >still get the job done?

> There are many options but depends of the users and the use case. Modes
> like vim, cua-mode and similar aproaches for rectangular work, multiple
> cursors. A real selection as anything else... highlighted. Don't have a
> region when you dont want a region...

> It depends on the workflow... Simple for me may not be simpler for you. 

You've completely misconstrued my meaning.  By simple, I meant something
like the aesthetic of minimality.  Point and mark define a region.  There
is nothing left in that set of concepts that you could take away and
still have a usable editor.  At the same time, point and mark are fully
adequate for efficient working.

That's not to say that some people prefer less elegance and more
elaborate facilities (such as transient-mark-mode).  That's fine.  

> >> 2) I agree with the Eli's approach to find a mean point that makes
> >> less unhappy most of the people (if possible).

> >That means, I think, being able to customise Emacs to suit ones' own
> >preferences.


> Also agree. For example: If i dont like to have always a region do I
> have an alternative?

<sigh> The region is simply a portion of your buffer.  What you're
suggesting is epistemologically incoherent.  It's "if I don't like always
to have a portion of my buffer do I have an alternative?".  No, Emacs
can't support such nonsense.  Sorry.

I wonder just how widespread this misconception is in Emacs users.

> >> 3) But interface changes are needed to survive, they require care to
> >> avoid conflicts and reduce the collapse with backward compatibility,
> >> but are needed.

> >> NEVERTHELESS

> >> The mark-point approach is not a fundamental emacs thing, it is just
> >> a design choice enforced for technical limitations 40 years ago
> >> (like the vi modes, the meta-hyper-syntax and so on) This means that
> >> (citing Bill Joy about vi) it was created for a world that doesn't
> >> exist anymore.  So it can (and should) be updated/upgraded as many
> >> other things in emacs and any long living project.

> >I can't let this pass without comment.  The point, mark, region
> >approach (I'm considering it here without the complications introduced
> >by transient-mark-mode) is a stroke of genius, combining austere
> >simplicity with great flexibility and ease of use.  How well do you
> >understand this approach?

> This is your very personal opinion. It is a good approach, but there
> are others equally good and in my opinion some better and more logical
> for some use cases. (Or just faster)

It's not just my personal opinion, it's objective, too.  Your assertion
that "the mark-point approach is not a fundamental emacs thing" is, I
think, a personal wish, but unfounded.  This approach is baked into so
many Emacs primitives and higher level commands that to try to remove it
would be essentially impossible.  It would likely be less work to write a
new editor from scratch.

> Some people likes to use vim with its insert and copy modes. Some
> people likes to use the mouse... They are much much more than the ones
> that likes emacs in tty... Some people uses windows...

Emacs aims to cater for all these user preferences, and, I think, does a
reasonable job at this.  How many other modern editors support a tty?

> There are standards in all the interfaces and programs. A user dont
> need to read anything to know how to do basic stuf anywhere. Even gnu
> programs have created many of these standards. (Screen tmux bash xterm) 

Emacs is about more than just doing basic stuff.  It's a powerful tool
with extreme user friendliness.  This necessarily means it's not going to
be beginner friendly, or easy to learn.

> In my telegram emacs group 80 % of the users use evil mode or
> spacemacs... Does it means something to you as a developer?

If that usage pattern is widespread, then it suggests that these
facilities are worth maintaining, or possibly incorporating into the
Emacs core, as the case may be.

> >Just what were these technical limitations which you assert gave rise
> >to point/mark/region?  The world which gave rise to it may no longer
> >exist, but the idea is so good that it remains powerful and relevant.

> In this thread I only see you with so strong feelings that it is a kind
> of divine perfect iluminated idea and should be as is for the universal
> equilibrium.

Again, what were these supposed technical limitations which you say gave
rise to point/mark/region?  I suggest to you that there were and are no
such technical limitations.

[ .... ]

> >I fear that by "updated/upgraded" you really mean "made more
> >complicated, less flexible, and (possibly) dumbed down".

> You dont know... Maybe after all eli or anyone comes with a most genius
> and iluminated idea. Or if we ask the users they can propose
> alternatives that we havent even imagined.

Emacs is an open project.  Anybody is welcome to contribute and implement
new ideas, and if they are coherent and worthwhile will likely be
incorporated into Emacs.  transient-mark-mode was such an idea, which was
quickly incorporated, eventually becoming the default setting (something
I think was unwise).

> >You say "it should be updated/upgraded".  Somebody has to do this
> >work.

> I didnt say that. In fact i dont have actually any urgent problem with
> this. But i dont like the orthodox idea of consider it as perfect and
> better than anything else, because it isnt.

Perfect, no, but better than anything else, for some values of "better",
then yes.  But, as just said, anybody who considers the point/mark
mechanism inadequate is welcome to enhance it, or to add some other
mechanism.

> I am not ready to contribute... But this kind of aptitude and strong
> strict opinions about a simple detail dont help to attract new
> developers.

Doesn't it?  There has been a steady stream of new people actively
contributing in the last few years.

> The same if you suggest to use a different editor when anyone proposes
> to change something because you consider it is a fundamental axiom.

Point/mark _is_ fundamental to Emacs, and hardly possible to remove.  And
good as Emacs is, I would not maintain it is suitable for everybody.

> >Are you prepared to contribute, yourself?

>  WIP.

> >Proposals for changes, particularly drastic changes, tend to be much
> >better received here when they come in the form of patches rather than
> >just vague ideas.

> Totaly right. 

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: delete-selection-mode as default

[Elias Mårtenson]

[-- Attachment #1: Type: text/plain, Size: 552 bytes --]

On Mon, 17 Sep 2018, 10:21 Alan Mackenzie, <acm@muc.de> wrote:

>
> <sigh> The region is simply a portion of your buffer.  What you're
> suggesting is epistemologically incoherent.  It's "if I don't like always
> to have a portion of my buffer do I have an alternative?".  No, Emacs
> can't support such nonsense.  Sorry.


It seems to me that the desires of hw could be fulfilled by simply
disabling the mark whenever the region becomes inactive.

It does sound like something I would never want to use, but it does seem
like what is being suggested.

[-- Attachment #2: Type: text/html, Size: 990 bytes --]

Re: delete-selection-mode as default

[Alan Mackenzie]

Hello, Elias.

On Mon, Sep 17, 2018 at 13:46:54 +0800, Elias Mårtenson wrote:
> On Mon, 17 Sep 2018, 10:21 Alan Mackenzie, <acm@muc.de> wrote:

> > <sigh> The region is simply a portion of your buffer.  What you're
> > suggesting is epistemologically incoherent.  It's "if I don't like always
> > to have a portion of my buffer do I have an alternative?".  No, Emacs
> > can't support such nonsense.  Sorry.


> It seems to me that the desires of hw could be fulfilled by simply
> disabling the mark whenever the region becomes inactive.

This can be done by setting mark-even-if-inactive to nil.  This has been
going around this list for several days, now.

It's been getting on my nerves that (unwittingly) false accusations
about the region, that its "existence" (whatever that might mean)
somehow represents an inconvenience or danger, are doing the rounds on
this list.  It only takes a little clear thought to see how ridiculous
this is.

> It does sound like something I would never want to use, but it does seem
> like what is being suggested.

Yes, I think so too.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: delete-selection-mode as default

[hw]

Elias Mårtenson <lokedhs@gmail.com> writes:

> On Mon, 17 Sep 2018, 10:21 Alan Mackenzie, <acm@muc.de> wrote:
>
>>
>> <sigh> The region is simply a portion of your buffer.  What you're
>> suggesting is epistemologically incoherent.  It's "if I don't like always
>> to have a portion of my buffer do I have an alternative?".  No, Emacs
>> can't support such nonsense.  Sorry.
>
>
> It seems to me that the desires of hw could be fulfilled by simply
> disabling the mark whenever the region becomes inactive.
>
> It does sound like something I would never want to use, but it does seem
> like what is being suggested.

Yes and no:  With mark-even-if-inactive set to nil, it is not so
relevant for me that the mark be disabled.

That leaves the option of not disabling it, in which case it might be
useful to use the mark for navigation.  To do that, I only need to put a
command that changes point and mark on C-x C-x, as Eli suggested.  I
never used that, but that doesn't mean it can't be useful when it is not
involved with making selections because it's easier to press C-spc than
to set a register or a bookmark.

It also leaves the issue of persistent selections.  Yuri and Drew said
that it would be a huge amount of work, and Yuri explained how the
appeal of persistent selections may be limited when multiple buffers and
windows get involved.  I'd still like having that, but it doesn't really
provide additional functionality other than the possibility of multiple
persistent selections per buffer which I never missed --- and apparently
can already have with zones, as Drew suggested.

The region still won't make any sense to me, and it doesn't need to.


What new users might want or expect and what might make sense to them is
another question.

RE: delete-selection-mode as default

[Drew Adams]

> It also leaves the issue of persistent selections.  Yuri and Drew said
> that it would be a huge amount of work, 

I don't think I said that (but I'm not going to search all that I've said
in this thread). I pointed out various things that could be done to
implement multiple persistent selections, in particular pointing to
what is already available in `second-sel.el' and `zones.el'.

> and Yuri explained how the
> appeal of persistent selections may be limited when multiple buffers and
> windows get involved.  I'd still like having that, but it doesn't really
> provide additional functionality other than the possibility of multiple
> persistent selections per buffer which I never missed --- and apparently
> can already have with zones, as Drew suggested.

To be clear, the zones in a set (list) of zones can be in the same
buffer, which might or might not be the current buffer, or they
can be in different buffers. You can have multiple sets (lists) of
zones, and any zone in any of them can have its limit positions
in any buffer.

The limits defining a given zone can be unspecified as to their
buffer, in which case that zone can be used in any buffer. The
only requirement on the two limits of a given zone is that if they
each specify a buffer then they must specify the same buffer
(otherwise the behavior is undefined).

Any zone limit can be an Emacs marker, a "readable marker"
(which can be saved to disk), or a positive integer.

Re: delete-selection-mode as default

[Stefan Monnier]

> Fine, then we agree.  The above issue is not relevant to what I
> perceive as the main problem here: how to give us a way to allow
> turning on delete-selection-mode without alienating users who have no
> use for it and very much dislike its effects, in particular when those
> effects are unintended.

AFAIK d-s-m has currently only 2 effects:
- delete the selection before self-insert-command
- same before yank

In both cases, if that's not what the user intended, an important
question is: why was the region active before those commands?


        Stefan

Re: delete-selection-mode as default

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sat, 15 Sep 2018 11:02:54 -0400
> 
> > Fine, then we agree.  The above issue is not relevant to what I
> > perceive as the main problem here: how to give us a way to allow
> > turning on delete-selection-mode without alienating users who have no
> > use for it and very much dislike its effects, in particular when those
> > effects are unintended.
> 
> AFAIK d-s-m has currently only 2 effects:
> - delete the selection before self-insert-command
> - same before yank
> 
> In both cases, if that's not what the user intended, an important
> question is: why was the region active before those commands?

Because the user did "C-x C-x"?

Re: delete-selection-mode as default

[Stefan Monnier]

>> > Fine, then we agree.  The above issue is not relevant to what I
>> > perceive as the main problem here: how to give us a way to allow
>> > turning on delete-selection-mode without alienating users who have no
>> > use for it and very much dislike its effects, in particular when those
>> > effects are unintended.
>> AFAIK d-s-m has currently only 2 effects:
>> - delete the selection before self-insert-command
>> - same before yank
>> In both cases, if that's not what the user intended, an important
>> question is: why was the region active before those commands?
> Because the user did "C-x C-x"?

So again the problem is not with d-s-m but with C-x C-x, then.

I think many users who are heavy users of the marks for navigation would
benefit from a "halfway" setting for transient-mark-mode, where commands
like C-M-SPC, M-h etc... still activate the region, but where C-SPC, and
C-x C-x don't.


        Stefan

Re: delete-selection-mode as default

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: emacs-devel@gnu.org
> Date: Sat, 15 Sep 2018 14:30:35 -0400
> 
> >> > Fine, then we agree.  The above issue is not relevant to what I
> >> > perceive as the main problem here: how to give us a way to allow
> >> > turning on delete-selection-mode without alienating users who have no
> >> > use for it and very much dislike its effects, in particular when those
> >> > effects are unintended.
> >> AFAIK d-s-m has currently only 2 effects:
> >> - delete the selection before self-insert-command
> >> - same before yank
> >> In both cases, if that's not what the user intended, an important
> >> question is: why was the region active before those commands?
> > Because the user did "C-x C-x"?
> 
> So again the problem is not with d-s-m but with C-x C-x, then.

I never said there was some "problem" with delete-selection-mode.
It's not delete-selection-mode that is the problem, it's the fact that
we use the region for 3 different purposes.

> I think many users who are heavy users of the marks for navigation would
> benefit from a "halfway" setting for transient-mark-mode, where commands
> like C-M-SPC, M-h etc... still activate the region, but where C-SPC, and
> C-x C-x don't.

Did you read any of my messages?  I think we can have that cake and
eat it, too.

Re: delete-selection-mode as default

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > In both cases, if that's not what the user intended, an important
  > question is: why was the region active before those commands?

It could be because the user typed C-SPC to mark one end of the
region.  Or because of C-x C-x.  There are commends for which an
active region changes the behavior.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

RE: delete-selection-mode as default

[Drew Adams]

> > You've decided that d-s-m won't be on by default
> > anytime soon.
> 
> No such decision was made.

Good to hear. I (mis)understood that, based on
this from RMS on 09/10:

   ELi and I, the Emacs maintainers, are both
   opposed to making delete-selection-mode
   the default.

I misread that as a decision by the maintainers.

I should also have noticed that he immediately
followed that with "Please don't do that." It was
essentially a vote, I guess, but a vote given extra
weight by the maintainer attribution.

(I was in fact surprised to hear that Richard is
again participating as a maintainer. Does that
mean we have three now? Anyway, I, for one,
would welcome it.)

Re: delete-selection-mode as default

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Good to hear. I (mis)understood that, based on
  > this from RMS on 09/10:

  >    ELi and I, the Emacs maintainers, are both
  >    opposed to making delete-selection-mode
  >    the default.

  > I misread that as a decision by the maintainers.

That's what I meant it as.  Eli had said he was against this change.
I hope he is against it once again.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: delete-selection-mode as default

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: eliz@gnu.org, drew.adams@oracle.com, hw@adminart.net,
> 	spacibba@aol.com, joostkremers@fastmail.fm,
> 	npostavs@gmail.com, emacs-devel@gnu.org, yurivkhan@gmail.com,
> 	acm@muc.de, phillip.lord@russet.org.uk
> Date: Tue, 02 Oct 2018 20:22:44 -0400
> 
>   > Good to hear. I (mis)understood that, based on
>   > this from RMS on 09/10:
> 
>   >    ELi and I, the Emacs maintainers, are both
>   >    opposed to making delete-selection-mode
>   >    the default.
> 
>   > I misread that as a decision by the maintainers.
> 
> That's what I meant it as.  Eli had said he was against this change.
> I hope he is against it once again.

My opinion was and remains that delete-selection-mode cannot be turned
on by default without also taking some additional measures.  My
suggestions for one possible set of such measures drowned in the
irrelevant noise.  If someone wants to implement some variant of my
suggestions, or come up with a different idea to the same effect, we
can then resume the discussion whether delete-selection-mode could be
enabled by default together with implementing these additional
measures.

The "no such decision was made" part wanted to tell that this
"discussion" was hardly conducive to any decision-making, and
consequently no decisions were made.  Each one remains of their
previous opinions, for now.

Re: delete-selection-mode as default (WAS: Some developement questions)

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

It seems to me that the people who like delete-selection-mode
are those who are used to some similar behavior in some other
editor and have not truly got used to Emacs.

They have two possible paths to follow: get used to Emacs,
or stay in the middle.  We can provide various features to
make Emacs serve each group.  But here we have a proposal
to make the defaults serve cater primarily to those who don't want to
get used to Emacs, rather than those who want to get used to Emacs,
and also at the expense of experienced Emacs users.

I am against making delete-selection-mode the default.

However, there might be some way of helping new users choose this and
other settings based on whether they want to truly get used to Emacs
or just use it occasionally.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: delete-selection-mode as default

[Stefan Monnier]

> It seems to me that the people who like delete-selection-mode
> are those who are used to some similar behavior in some other
> editor and have not truly got used to Emacs.

I think you take it for granted that the non-delete-selection-mode
behavior of Emacs is fundamentally superior.  I disagree.

Both behaviors have their advantages and disadvantages, but I don't see
either of them clearly superior to the other.


        Stefan

Re: delete-selection-mode as default

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I think you take it for granted that the non-delete-selection-mode
  > behavior of Emacs is fundamentally superior.

"Fundamentally" is not what I'm talking about.

delete-selection-mode is designed for the interface scheme where you
select a region with the mouse.  That's where we copied it from.
In that interface scheme, delete-selection-mode fits.

The traditional Emacs interface is that you edit with the
keyboard.  What fits that interface is that Backspace deletes
one character.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: delete-selection-mode as default

[Yuri Khan]

On Sun, Sep 9, 2018 at 1:24 PM Richard Stallman <rms@gnu.org> wrote:

> delete-selection-mode is designed for the interface scheme where you
> select a region with the mouse.  That's where we copied it from.
> In that interface scheme, delete-selection-mode fits.

This is inaccurate. delete-selection-mode works very well with
Shift+arrows region selection.

RE: delete-selection-mode as default

[Drew Adams]

>   > I think you take it for granted that the non-delete-selection-mode
>   > behavior of Emacs is fundamentally superior.
> 
> "Fundamentally" is not what I'm talking about.
> 
> delete-selection-mode is designed for the interface scheme where you
> select a region with the mouse.  That's where we copied it from.
> In that interface scheme, delete-selection-mode fits.

I can't speak to its history - that may be where you copied it from.

But its design and its behavior fit just as well with selecting the
region in any way, not just with a mouse. The region can be
selected programmatically, by setting the mark and moving
point interactively, using shift-selection, or any other method
that might exist to select the region.

> The traditional Emacs interface is that you edit with the
> keyboard.  What fits that interface is that Backspace deletes
> one character.

The traditional Emacs interface is defined how? Do you mean
Emacs in a terminal? No faces? No mouse support? No text
properties? How far back do you go, to find it?

Or by traditional do you just mean the default behavior,
which means of course that `d-s-m' is off?

In any case, `d-s-m' works fine when editing with only the
keyboard, with both keyboard and mouse, and with only
the mouse (or foot pedals or...).

Please don't suggest that `d-s-m' behavior is in some way
limited to use with a mouse or that it in some way promotes
or is connected with any particular OS (e.g. MS Windows) -
it's not.

Re: delete-selection-mode as default

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I can't speak to its history - that may be where you copied it from.

Your ignorance does not trump my memory.

  > But its design and its behavior fit just as well with selecting the
  > region in any way, not just with a mouse.

It will operate regardless of how the region was selected, but the
case it makes sense for is when the kind of input used for selection
is something quite different from the kind of input used for the
subsequent deletion.

  > The traditional Emacs interface is defined how? Do you mean
  > Emacs in a terminal? No faces? No mouse support? No text
  > properties? How far back do you go, to find it?

These questions don't need to be answered.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)