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

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)

[Drew Adams]

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

Yes, sorry; my bad.

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

Yes, those are useful use cases. But so is typing to replace, I think.

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.

visual-region-mode? (was: delete-selection-mode as default)

[hw]

charles@aurox.ch (Charles A. Roelli) writes:

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

Whether regions can be active or not, and whether "active" means that
they limit or extend operations to themselves, or both, might depend on
settings and doesn't necessarily need to be shown all the time.

> like a mode line indicator.

Such a mode line indicator would need to show which regions are active
when there several and in which way each one of them is active because
there are multiple ways of being active.

Perhaps it could generally show if any region is active and change when
point is within a region to show more of its details.

> We would then also need bindings for activating and deactivating the
> region, and for turning the visual aid on and off.

Another C-spc after starting to mark a region might do to end the
marking.

What would the advantage of hidden regions be?  When something is within
a region, it should be highlighted, and when it is no longer
highlighted, it should no longer be within a region.

Are these hidden regions a remnant of technical limitations that made it
advisable not to highlight the selection?

Perhaps region selections could be remembered in registers to make it
easier to re-create them once they were disabled to suppress the
highlighting.

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

Doesn't that enable transient-mark-mode?  If I wanted t-m-m, I could
just leave it enabled to begin with.

I tried with t-m-m disabled, and I don't see what the point of having it
disabled is.  Regions are not protected any better, and I'd have to be
stupid to select a region to do something I want to affect the whole
buffer.

>> 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 could be accompanied by a region-mode in which nothing can be done to
and with anything outside of the regions.

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

Isn't is easier to use registers instead?

Re: visual-region-mode? (was: delete-selection-mode as default)

[Charles A. Roelli]

> From: hw <hw@adminart.net>
> Date: Mon, 10 Sep 2018 13:52:06 +0200
>
> >> 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,
> 
> Whether regions can be active or not, and whether "active" means that
> they limit or extend operations to themselves, or both, might depend on
> settings and doesn't necessarily need to be shown all the time.

Yes.  Ultimately the choice should be left to the user.
 
> > like a mode line indicator.
> 
> Such a mode line indicator would need to show which regions are active
> when there several and in which way each one of them is active because
> there are multiple ways of being active.

Can you say how there can be multiple regions active, and how there
can be "multiple ways of being active"?  The region is normally
defined as "the text between point and mark", for one, and whether the
mark is active depends on the value of the buffer-local variable
'mark-active'.

> Perhaps it could generally show if any region is active and change when
> point is within a region to show more of its details.

Point always delimits the region, so I'm not sure what more details we
could show about it.
 
> > We would then also need bindings for activating and deactivating the
> > region, and for turning the visual aid on and off.
> 
> Another C-spc after starting to mark a region might do to end the
> marking.

C-SPC (without a prefix argument) always pushes a mark, so it always
alters the region (unless point is already at the mark).  C-u C-SPC
sets point where the mark is, and pops the mark ring, effectively
restoring the previous region.  We should keep this behavior.
 
> What would the advantage of hidden regions be?  When something is within
> a region, it should be highlighted, and when it is no longer
> highlighted, it should no longer be within a region.

Again, in Emacs, as long there is a mark in the current buffer, there
is always a "region".  The user might want it highlighted for various
reasons, possibly not covered by the current implementation, where
Emacs highlights the region only when 'mark-active' is non-nil.
 
> Are these hidden regions a remnant of technical limitations that made it
> advisable not to highlight the selection?

No, they stem from convenience.  For example, typing C-M-a in a source
code buffer moves point to the beginning of the current defun, pushing
a mark where point was.  Afterwards, typing C-u C-SPC restores point
and mark (i.e. the region) to where they were before you typed C-M-a.
During editing this is very helpful.  Highlighting the region at any
of these steps might be helpful for the user, but Emacs can't know
exactly when -- which is one argument for allowing to toggle the
highlighting dynamically as necessary, independently of whether the
mark is ever "active".

> Perhaps region selections could be remembered in registers to make it
> easier to re-create them once they were disabled to suppress the
> highlighting.

As seen above, use of C-u C-SPC effectively restores the region at
some previous point in editing.  Certainly, it would be nice to have
some register key to push (cons (point-marker) (mark-marker)) into a
register to come back to it later.  Until we have that, "C-x 4 c C-x n
n C-x r SPC <register>" also works, via an indirect buffer, though
it's a mouthful.

> >> 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.
> 
> Doesn't that enable transient-mark-mode?  If I wanted t-m-m, I could
> just leave it enabled to begin with.

Yes, it is enabled temporarily.

> I tried with t-m-m disabled, and I don't see what the point of having it
> disabled is.  Regions are not protected any better, and I'd have to be
> stupid to select a region to do something I want to affect the whole
> buffer.

With t-m-m off, you can make use of the mark without randomly
activating it and causing certain commands to respond differently.
However, there are tradeoffs: commands like "query-replace" will do
their work on the region only when the mark is "active", so to use
that capability, you need "C-u C-x C-x" to temporarily activate the
mark.

> >> 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 could be accompanied by a region-mode in which nothing can be done to
> and with anything outside of the regions.

Working on a specific region can often be done conveniently from an
indirect buffer, as in the earlier example.

> >> 						       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
> 
> Isn't is easier to use registers instead?

It might be.  I use both, but for different purposes.

Re: visual-region-mode? (was: delete-selection-mode as default)

[Yuri Khan]

On Tue, Sep 11, 2018 at 3:01 AM Charles A. Roelli <charles@aurox.ch> wrote:

> Can you say how there can be multiple regions active, and how there
> can be "multiple ways of being active"?  The region is normally
> defined as "the text between point and mark", for one, and whether the
> mark is active depends on the value of the buffer-local variable
> 'mark-active'.

By the way, this definition of region is flawed.

The mark is buffer-local, while the point is buffer-and-window-local.
Display a buffer B in windows X and Y, mark a region in window X, then
switch to window Y. Suddenly, an entirely unrelated fragment of text
is highlighted as region.

A consistent definition of a persistent region would make it an
interval between two buffer-local markers, both of which are distinct
from the point.

A consistent definition of a transient region would make the mark also
buffer-and-window-local, so that buffer B in windows X and Y could
have completely independently marked regions.

Re: visual-region-mode? (was: delete-selection-mode as default)

[Charles A. Roelli]

> From: Yuri Khan <yurivkhan@gmail.com>
> Date: Tue, 11 Sep 2018 12:43:16 +0700
>
> > Can you say how there can be multiple regions active, and how there
> > can be "multiple ways of being active"?  The region is normally
> > defined as "the text between point and mark", for one, and whether the
> > mark is active depends on the value of the buffer-local variable
> > 'mark-active'.
> 
> [...]
>
> A consistent definition of a transient region would make the mark also
> buffer-and-window-local, so that buffer B in windows X and Y could
> have completely independently marked regions.

In that case, pushing a mark in window X, then switching to window Y
and popping the mark would not necessarily place point where the mark
was pushed in window X, since window Y might have its own mark.  That
could be surprising behavior.  The handling of the mark-ring would
also be complicated.

Re: visual-region-mode? (was: delete-selection-mode as default)

[Yuri Khan]

On Wed, Sep 12, 2018 at 1:24 AM Charles A. Roelli <charles@aurox.ch> wrote:

> > A consistent definition of a transient region would make the mark also
> > buffer-and-window-local, so that buffer B in windows X and Y could
> > have completely independently marked regions.
>
> In that case, pushing a mark in window X, then switching to window Y
> and popping the mark would not necessarily place point where the mark
> was pushed in window X, since window Y might have its own mark.  That
> could be surprising behavior.  The handling of the mark-ring would
> also be complicated.

I thought about it some more.

We have a notion of mark that is somewhat overloaded. On the one hand,
there is the mark ring and the global mark ring whose purpose in life
is to help the user navigate back to positions they visited earlier.
On the other hand, the mark is used as one of the two delimiters of
the region.

It seems to me these two uses of the mark are mutually disjoint, and
it might be a better model if they were decoupled.

Re: visual-region-mode?

[Andreas Schwab]

On Sep 12 2018, Yuri Khan <yurivkhan@gmail.com> wrote:

> It seems to me these two uses of the mark are mutually disjoint, and
> it might be a better model if they were decoupled.

There is already bookmark to handle marks independent of the region.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: visual-region-mode?

[Yuri Khan]

On Wed, Sep 12, 2018 at 1:59 PM Andreas Schwab <schwab@suse.de> wrote:
>
> On Sep 12 2018, Yuri Khan <yurivkhan@gmail.com> wrote:
>
> > It seems to me these two uses of the mark are mutually disjoint, and
> > it might be a better model if they were decoupled.
>
> There is already bookmark to handle marks independent of the region.

How are bookmarks relevant here? They add a way of navigating other
than by popping the mark ring, but they do not eliminate the
interdependency between the region and the mark ring.

Re: visual-region-mode?

[Andreas Schwab]

On Sep 12 2018, Yuri Khan <yurivkhan@gmail.com> wrote:

> On Wed, Sep 12, 2018 at 1:59 PM Andreas Schwab <schwab@suse.de> wrote:
>>
>> On Sep 12 2018, Yuri Khan <yurivkhan@gmail.com> wrote:
>>
>> > It seems to me these two uses of the mark are mutually disjoint, and
>> > it might be a better model if they were decoupled.
>>
>> There is already bookmark to handle marks independent of the region.
>
> How are bookmarks relevant here?

They are the better model you are looking for.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: visual-region-mode? (was: delete-selection-mode as default)

[Charles A. Roelli]

> From: Yuri Khan <yurivkhan@gmail.com>
> Date: Wed, 12 Sep 2018 12:12:26 +0700
> 
> > > A consistent definition of a transient region would make the mark also
> > > buffer-and-window-local, so that buffer B in windows X and Y could
> > > have completely independently marked regions.
> >
> > In that case, pushing a mark in window X, then switching to window Y
> > and popping the mark would not necessarily place point where the mark
> > was pushed in window X, since window Y might have its own mark.  That
> > could be surprising behavior.  The handling of the mark-ring would
> > also be complicated.
> 
> I thought about it some more.
> 
> We have a notion of mark that is somewhat overloaded. On the one hand,
> there is the mark ring and the global mark ring whose purpose in life
> is to help the user navigate back to positions they visited earlier.
> On the other hand, the mark is used as one of the two delimiters of
> the region.
> 
> It seems to me these two uses of the mark are mutually disjoint, and
> it might be a better model if they were decoupled.

The mark ring and the region are even more tightly coupled: C-u C-SPC
not only jumps to the mark, it also sets the mark from the most recent
mark on the mark ring, effectively restoring the previous region.  It
could be called the "region ring".  And since it so happens that the
boundaries of "regions" are often places of interest to the user,
maybe it makes good sense to combine these two uses of the mark as
delimiter of the region, and the mark as a navigational buoy.

Re: visual-region-mode?

[Juri Linkov]

> By the way, this definition of region is flawed.
>
> The mark is buffer-local, while the point is buffer-and-window-local.
> Display a buffer B in windows X and Y, mark a region in window X, then
> switch to window Y. Suddenly, an entirely unrelated fragment of text
> is highlighted as region.
>
> A consistent definition of a persistent region would make it an
> interval between two buffer-local markers, both of which are distinct
> from the point.
>
> A consistent definition of a transient region would make the mark also
> buffer-and-window-local, so that buffer B in windows X and Y could
> have completely independently marked regions.

Yes, this is an annoying problem.  As a workaround, it's easy
to make the mark buffer-and-window-local with this simple code:

  (defvar-local mark-active-window nil)

  (add-hook 'activate-mark-hook   (lambda () (setq mark-active-window (selected-window))))
  (add-hook 'deactivate-mark-hook (lambda () (setq mark-active-window nil)))

  (defun redisplay--update-mark-active-window (window)
    (when mark-active-window
      (setq mark-active (eq mark-active-window window))))

  (add-to-list 'pre-redisplay-functions #'redisplay--update-mark-active-window)

I'm not sure if a new customizable option is necessary to define the
preferable behavior like with the option `highlight-nonselected-windows'.

Re: visual-region-mode?

[hw]

charles@aurox.ch (Charles A. Roelli) writes:

>> From: hw <hw@adminart.net>
>> Date: Mon, 10 Sep 2018 13:52:06 +0200
>>
>> >> 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,
>> 
>> Whether regions can be active or not, and whether "active" means that
>> they limit or extend operations to themselves, or both, might depend on
>> settings and doesn't necessarily need to be shown all the time.
>
> Yes.  Ultimately the choice should be left to the user.
>  
>> > like a mode line indicator.
>> 
>> Such a mode line indicator would need to show which regions are active
>> when there several and in which way each one of them is active because
>> there are multiple ways of being active.
>
> Can you say how there can be multiple regions active, and how there
> can be "multiple ways of being active"?  The region is normally
> defined as "the text between point and mark", for one, and whether the
> mark is active depends on the value of the buffer-local variable
> 'mark-active'.

I don't think there can currently be multiple regions at the same time.
That doesn't mean this couldn't be implemented.

There are multiple ways for a region to be active because there are at
least three ways in which the activeness of a region can have an
influence on functions/commands.  Active can mean:


+ limit commands to a region (like query-replace)

+ extend commands to a region (like backward-delete-char)

+ both of the above (I don't have a good example)


The first one was probably the original intention, the second one seems
like a bug.  The last one is probably questionable.  You may see
delete-selection-mode as an example in that otherwise harmless
keystrokes suddenly operate on a whole region.

I can understand the original intention.  I don't understand how
disabling transient-mark-mode could have an advantage --- unless, for
some reason, you have a bad habit of abusing the mark for naviation ---
and I don't understand why regions are not always highlighted regardless
if are active or not.  That means that something not highlighted as such
is not a region.

As to the definition of the region:  I've never seen it that way.  The
region is what is currently highlighted.  I don't use and don't like
hidden regions.  They are a design flaw because when I press C-w,
something of unknown extend is being deleted, and when press M-w,
something of unknown extend is being copied and replaces what I kept on
the clipboard.

These hidden regions always make me feel uneasy.  It's like you're being
forced to walk around with a loaded gun, safety off, once you only even
touched the trigger without firing a shot because that sets a mark.  The
only way to get rid of this gun is to kill the buffer --- or is there
another way?

I expect the mark to be forgotten, or at least to disappear, right away
after doing something with a region.

As to multiple regions, it might be nice to have them.

>> Perhaps it could generally show if any region is active and change when
>> point is within a region to show more of its details.
>
> Point always delimits the region, so I'm not sure what more details we
> could show about it.

That would be different if there were multiple regions.

>> > We would then also need bindings for activating and deactivating the
>> > region, and for turning the visual aid on and off.
>> 
>> Another C-spc after starting to mark a region might do to end the
>> marking.
>
> C-SPC (without a prefix argument) always pushes a mark, so it always
> alters the region (unless point is already at the mark).  C-u C-SPC
> sets point where the mark is, and pops the mark ring, effectively
> restoring the previous region.  We should keep this behavior.

How am I supposed to know where a mark was?  Why would I try to confuse
myself with C-u C-spc?  In which way is the position of the mark
adjusted so that it sticks with the same contents of the buffer, which
it would need to do to be of any use?

I expect the mark to be gone once I used the region.

>> What would the advantage of hidden regions be?  When something is within
>> a region, it should be highlighted, and when it is no longer
>> highlighted, it should no longer be within a region.
>
> Again, in Emacs, as long there is a mark in the current buffer, there
> is always a "region".

How would that make sense?  I expect the mark to be gone once I used the
region.

> The user might want it highlighted for various reasons, possibly not
> covered by the current implementation, where Emacs highlights the
> region only when 'mark-active' is non-nil.

Yes, and that leads to misunderstandings, like d-s-m.  It doesn't make
any sense to claim that there is a region when there is none highlighted
and only creates the inconsistency that an arbitrary part of a buffer
can be deleted or copied, accidentally or intentionally, i. e. that
something can be done with a region while the region is not active and
nothing should possibly be done with it.

>> Are these hidden regions a remnant of technical limitations that made it
>> advisable not to highlight the selection?
>
> No, they stem from convenience.  For example, typing C-M-a in a source

That key binding only works when you can use Alt instead of ESC.

> code buffer moves point to the beginning of the current defun, pushing
> a mark where point was.  Afterwards, typing C-u C-SPC restores point
> and mark (i.e. the region) to where they were before you typed
> C-M-a. During editing this is very helpful.

This is only sometimes helpful, provided that the Alt key works.  When
it doesn't, you'd have to bind the function to another key.  All in all,
even with the Alt key working, these key bindings are so awkward that I
would never use this.  It's far easier to just scroll up and to use
bookmarks or registers.

> Highlighting the region at any of these steps might be helpful for the
> user, but Emacs can't know exactly when -- which is one argument for
> allowing to toggle the highlighting dynamically as necessary,
> independently of whether the mark is ever "active".

This is a problem of navigating source code (or other files) and has
nothing to do with regions or highlighting.

Or what has navigating between a current location and the beginning of a
function to do with selecting and highlighting parts of the contents of
a buffer in order to copy or to delete them, or to do something with
them like query-replace?

>> Perhaps region selections could be remembered in registers to make it
>> easier to re-create them once they were disabled to suppress the
>> highlighting.
>
> As seen above, use of C-u C-SPC effectively restores the region at
> some previous point in editing.

That I move around in a file as I see fit while reading or editing it
doesn't have anything to do with regions I might select to do something
with.  I might highlight a selection to make parts of source code stick
out as a reminder because they need to be fixed or worked upon in some
particular order.  I could use registers and/or bookmarks instead, but
it would be much more convenient to use highlighting and perhaps to be
able to jump through the selections.

Why would I want a region I have selected and highlighted to become
undone when I move around?

> Certainly, it would be nice to have some register key to push (cons
> (point-marker) (mark-marker)) into a register to come back to it
> later.  Until we have that, "C-x 4 c C-x n n C-x r SPC <register>"
> also works, via an indirect buffer, though it's a mouthful.

yeah

>> >> 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.
>> 
>> Doesn't that enable transient-mark-mode?  If I wanted t-m-m, I could
>> just leave it enabled to begin with.
>
> Yes, it is enabled temporarily.

Then what's the use of disabling t-m-m?

>> I tried with t-m-m disabled, and I don't see what the point of having it
>> disabled is.  Regions are not protected any better, and I'd have to be
>> stupid to select a region to do something I want to affect the whole
>> buffer.
>
> With t-m-m off, you can make use of the mark without randomly
> activating it and causing certain commands to respond differently.

The mark is only for setting the begin of a selection, nothing else.  I
expect it to be gone once I did something with the selection.

It doesn't even matter to me if there is a mark.  All I do is start
selecting somewhere and when it's selected, I do something with it, and
that's all there is to it.

Don't mix up a mark for navigational purposes with making and
highlighting selections.

> However, there are tradeoffs: commands like "query-replace" will do
> their work on the region only when the mark is "active", so to use
> that capability, you need "C-u C-x C-x" to temporarily activate the
> mark.

I'm really never using the mark.  When I want to do a query-replace
limited to a selection, I make the selection and then do the
query-replace.  With t-m-m disabled, I can't limit the query-replace to
a selection, so it's only a disadvantage to have it disabled --- and the
other disadvantage is that I can never 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.  
>> >
>> > I'd like this too.
>> 
>> It could be accompanied by a region-mode in which nothing can be done to
>> and with anything outside of the regions.
>
> Working on a specific region can often be done conveniently from an
> indirect buffer, as in the earlier example.

It's quite inconvenient because with that, the source tends to occupy
both frames I have on screen because I'd narrow the indirect buffer to
what I'm working on --- which is already another inconvenience --- and
need the other frame to look up things I can't see in the indirect
buffer because it's narrowed.  I've given up on it, it's just too
awkward.

As for doing other things, like replacing text in multiple parts of a
buffer, is that something that could be usefully done with indirect
buffers?  With multiple regions, I'd highlight some parts of the buffer,
do the replacement limited to these parts and would be done with it.
I'd be able to see all of the buffer while doing this.

Indirect buffers still hold all of the text, so instead of marking what
I want to work with, I'd have to narrow out what I'm not working with,
and IIRC, it's not possible to narrow a buffer "the other way round" so
that the parts I want to work with remain and all the rest of the buffer
is narrowed away.


So maybe you see how I'm saying that the concept of regions could use an
overhaul and how a visual-region-mode could be useful :)

Re: visual-region-mode?

[Charles A. Roelli]

> From: hw <hw@adminart.net>
> Date: Tue, 11 Sep 2018 23:56:11 +0200
>
> [...]
>
> As to the definition of the region:  I've never seen it that way.  The
> region is what is currently highlighted.  I don't use and don't like
> hidden regions.  They are a design flaw because when I press C-w,
> something of unknown extend is being deleted, and when press M-w,
> something of unknown extend is being copied and replaces what I kept on
> the clipboard.
> 
> These hidden regions always make me feel uneasy.  It's like you're being
> forced to walk around with a loaded gun, safety off, once you only even
> touched the trigger without firing a shot because that sets a mark.  The
> only way to get rid of this gun is to kill the buffer --- or is there
> another way?

This is where Emacs differs from other programs, I suppose.  It's
optimized for efficient use, even when the result can be a surprise to
the user.  Otherwise, in this case, C-w and M-w would do nothing with
no "active region".

> > C-SPC (without a prefix argument) always pushes a mark, so it always
> > alters the region (unless point is already at the mark).  C-u C-SPC
> > sets point where the mark is, and pops the mark ring, effectively
> > restoring the previous region.  We should keep this behavior.
> 
> How am I supposed to know where a mark was?  Why would I try to confuse
> myself with C-u C-spc?  In which way is the position of the mark
> adjusted so that it sticks with the same contents of the buffer, which
> it would need to do to be of any use?

Various commands set the mark, as documented in the manual.  When you
use them, normally a message appears in the echo area saying "Mark
set".  The mark is a standard Emacs marker, as described in (info
"(elisp) Markers"):

    A “marker” is a Lisp object used to specify a position in a buffer
    relative to the surrounding text.  A marker changes its offset from the
    beginning of the buffer automatically whenever text is inserted or
    deleted, so that it stays with the two characters on either side of it.
 
> >> What would the advantage of hidden regions be?  When something is within
> >> a region, it should be highlighted, and when it is no longer
> >> highlighted, it should no longer be within a region.
> >
> > Again, in Emacs, as long there is a mark in the current buffer, there
> > is always a "region".
> 
> How would that make sense?  I expect the mark to be gone once I used the
> region.

That's what transient-mark-mode tries to implement, I think.
 
> > The user might want it highlighted for various reasons, possibly not
> > covered by the current implementation, where Emacs highlights the
> > region only when 'mark-active' is non-nil.
> 
> Yes, and that leads to misunderstandings, like d-s-m.  It doesn't make
> any sense to claim that there is a region when there is none highlighted
> and only creates the inconsistency that an arbitrary part of a buffer
> can be deleted or copied, accidentally or intentionally, i. e. that
> something can be done with a region while the region is not active and
> nothing should possibly be done with it.

Again, that seems like the intention behind transient-mark-mode.  But
the implementation is, then, in a way incomplete: C-w still kills the
region, no matter whether it is active or not, in transient-mark-mode.

> >> Are these hidden regions a remnant of technical limitations that made it
> >> advisable not to highlight the selection?
> >
> > No, they stem from convenience.  For example, typing C-M-a in a source
> 
> That key binding only works when you can use Alt instead of ESC.

Does ESC C-a not work for you?  Or C-[ C-a?

> > code buffer moves point to the beginning of the current defun, pushing
> > a mark where point was.  Afterwards, typing C-u C-SPC restores point
> > and mark (i.e. the region) to where they were before you typed
> > C-M-a. During editing this is very helpful.
> 
> This is only sometimes helpful, provided that the Alt key works.  When
> it doesn't, you'd have to bind the function to another key.  All in all,
> even with the Alt key working, these key bindings are so awkward that I
> would never use this.  It's far easier to just scroll up and to use
> bookmarks or registers.

Yes, these work too.
 
> > Highlighting the region at any of these steps might be helpful for the
> > user, but Emacs can't know exactly when -- which is one argument for
> > allowing to toggle the highlighting dynamically as necessary,
> > independently of whether the mark is ever "active".
> 
> This is a problem of navigating source code (or other files) and has
> nothing to do with regions or highlighting.
> 
> Or what has navigating between a current location and the beginning of a
> function to do with selecting and highlighting parts of the contents of
> a buffer in order to copy or to delete them, or to do something with
> them like query-replace?

The places where the mark has been set are places of interest to the
user for some reason or another -- that's all.

> > As seen above, use of C-u C-SPC effectively restores the region at
> > some previous point in editing.
> 
> That I move around in a file as I see fit while reading or editing it
> doesn't have anything to do with regions I might select to do something
> with.  I might highlight a selection to make parts of source code stick
> out as a reminder because they need to be fixed or worked upon in some
> particular order.  I could use registers and/or bookmarks instead, but
> it would be much more convenient to use highlighting and perhaps to be
> able to jump through the selections.

This would be a good use case for registers storing regions, I think.
The mark ring is a useful tool, but it does not give easy, random
access to all previous selections.  We need a bug report for this.
 
> The mark is only for setting the begin of a selection, nothing else.  I
> expect it to be gone once I did something with the selection.
> 
> It doesn't even matter to me if there is a mark.  All I do is start
> selecting somewhere and when it's selected, I do something with it, and
> that's all there is to it.
> 
> Don't mix up a mark for navigational purposes with making and
> highlighting selections.

It's probably feasible to add a "type" field to the mark, indicating
where it came from (i.e., if it was set explicitly by the user, by a
certain command, from a mouse selection, ...).  Then we could offer
commands that jump between previous selections, or between previous
marks set by the user for navigation.

> > Working on a specific region can often be done conveniently from an
> > indirect buffer, as in the earlier example.
> 
> It's quite inconvenient because with that, the source tends to occupy
> both frames I have on screen because I'd narrow the indirect buffer to
> what I'm working on --- which is already another inconvenience --- and
> need the other frame to look up things I can't see in the indirect
> buffer because it's narrowed.  I've given up on it, it's just too
> awkward.
> 
> As for doing other things, like replacing text in multiple parts of a
> buffer, is that something that could be usefully done with indirect
> buffers?  With multiple regions, I'd highlight some parts of the buffer,
> do the replacement limited to these parts and would be done with it.
> I'd be able to see all of the buffer while doing this.

Not possible yet, I think (at least, without making N indirect buffers
for the N regions and running the replacement command in all of them).
But if we had some way to record the "type" of a previous mark (as
above), then we could offer a command to replace, for example, the
last N "active regions" in the buffer.  I think that might fit the
bill.

> Indirect buffers still hold all of the text, so instead of marking what
> I want to work with, I'd have to narrow out what I'm not working with,
> and IIRC, it's not possible to narrow a buffer "the other way round" so
> that the parts I want to work with remain and all the rest of the buffer
> is narrowed away.

I don't think that's possible yet.

RE: visual-region-mode?

[Drew Adams]

> > That I move around in a file as I see fit while reading or editing it
> > doesn't have anything to do with regions I might select to do something
> > with.  I might highlight a selection to make parts of source code stick
> > out as a reminder because they need to be fixed or worked upon in some
> > particular order.  I could use registers and/or bookmarks instead, but
> > it would be much more convenient to use highlighting and perhaps to be
> > able to jump through the selections.

With Bookmark+ you can use (temporary or persistent) bookmarks,
and they can highlight their locations in various ways. You can also
bookmark a region and have it activated when you later jump to it.
You can navigate among the bookmarks in various ways, including
cycling. You can create bookmarks without bothering to name them -
automatic naming based on a template (e.g. with buffer position).

With library `zones.el' you can define a list of multiple regions
(zones) in the same buffer or in a mix of buffers. You can cycle
among them, activating each in turn. You can move among them
as multiple narrowings. You can highlight and unhighlight them.
You can persist them as bookmarks.

> It's probably feasible to add a "type" field to the mark, indicating
> where it came from (i.e., if it was set explicitly by the user, by a
> certain command, from a mouse selection, ...).  Then we could offer
> commands that jump between previous selections, or between previous
> marks set by the user for navigation.

A zone has a start and end (like a region). It can also have an ID.
It can also have any Lisp values as additional data.

> > As for doing other things, like replacing text in multiple parts of a
> > buffer, is that something that could be usefully done with indirect
> > buffers?  With multiple regions, I'd highlight some parts of the buffer,
> > do the replacement limited to these parts and would be done with it.
> > I'd be able to see all of the buffer while doing this.
> 
> Not possible yet, I think (at least, without making N indirect buffers
> for the N regions and running the replacement command in all of them).
> But if we had some way to record the "type" of a previous mark (as
> above), then we could offer a command to replace, for example, the
> last N "active regions" in the buffer.  I think that might fit the
> bill.

You can add the region to a current list of zones (`C-x n a'). Then cycle
among them, activating each in turn (`C-x n r'); and do query-replace or
other actions on each one.

> > Indirect buffers still hold all of the text, so instead of marking what
> > I want to work with, I'd have to narrow out what I'm not working with,
> > and IIRC, it's not possible to narrow a buffer "the other way round" so
> > that the parts I want to work with remain and all the rest of the buffer
> > is narrowed away.
> 
> I don't think that's possible yet.

You can make a list of zones that is the complement of another list
of zones. 

If you also use library `isearch-prop.el' then you can make a list of
zones or its complement invisible, you can search the zones or their
complement. You can add text properties to the zones. When
searching you can dim the complement of the zones being searched,
and you can toggle to search the complement instead (and dim the
original zones).

----

https://www.emacswiki.org/emacs/download/zones.el

https://www.emacswiki.org/emacs/download/isearch-prop.el

https://www.emacswiki.org/emacs/BookmarkPlus

Re: visual-region-mode?

[Juri Linkov]

>> > The user might want it highlighted for various reasons, possibly not
>> > covered by the current implementation, where Emacs highlights the
>> > region only when 'mark-active' is non-nil.
>> 
>> Yes, and that leads to misunderstandings, like d-s-m.  It doesn't make
>> any sense to claim that there is a region when there is none highlighted
>> and only creates the inconsistency that an arbitrary part of a buffer
>> can be deleted or copied, accidentally or intentionally, i. e. that
>> something can be done with a region while the region is not active and
>> nothing should possibly be done with it.
>
> Again, that seems like the intention behind transient-mark-mode.  But
> the implementation is, then, in a way incomplete: C-w still kills the
> region, no matter whether it is active or not, in transient-mark-mode.

mark-even-if-inactive set to nil is much safer option - it prevents
accidental lossage caused by mistakenly typed C-w.

Re: visual-region-mode?

[hw]

Juri Linkov <juri@linkov.net> writes:

> [...]
>> Again, that seems like the intention behind transient-mark-mode.  But
>> the implementation is, then, in a way incomplete: C-w still kills the
>> region, no matter whether it is active or not, in transient-mark-mode.
>
> mark-even-if-inactive set to nil is much safer option - it prevents
> accidental lossage caused by mistakenly typed C-w.

Thanks, I changed it :)

Re: visual-region-mode?

[hw]

charles@aurox.ch (Charles A. Roelli) writes:

>> From: hw <hw@adminart.net>
>> Date: Tue, 11 Sep 2018 23:56:11 +0200
>>
>> [...]
>>
>> As to the definition of the region:  I've never seen it that way.  The
>> region is what is currently highlighted.  I don't use and don't like
>> hidden regions.  They are a design flaw because when I press C-w,
>> something of unknown extend is being deleted, and when press M-w,
>> something of unknown extend is being copied and replaces what I kept on
>> the clipboard.
>> 
>> These hidden regions always make me feel uneasy.  It's like you're being
>> forced to walk around with a loaded gun, safety off, once you only even
>> touched the trigger without firing a shot because that sets a mark.  The
>> only way to get rid of this gun is to kill the buffer --- or is there
>> another way?
>
> This is where Emacs differs from other programs, I suppose.  It's
> optimized for efficient use, even when the result can be a surprise to
> the user.  Otherwise, in this case, C-w and M-w would do nothing with
> no "active region".

What is efficient about hidden regions the way they are?

If killing or copying a region didn't happen to be bound to keys that
are rather unlikely to get pressed by mistake, the design flaw of being
able to do something with a non-highlighted region while
transient-mark-mode is enabled might be more obvious.

Disabling transient-mark-mode removes the possibility of highlighting
regions.  What is the purpose of that?

>> > C-SPC (without a prefix argument) always pushes a mark, so it always
>> > alters the region (unless point is already at the mark).  C-u C-SPC
>> > sets point where the mark is, and pops the mark ring, effectively
>> > restoring the previous region.  We should keep this behavior.
>> 
>> How am I supposed to know where a mark was?  Why would I try to confuse
>> myself with C-u C-spc?  In which way is the position of the mark
>> adjusted so that it sticks with the same contents of the buffer, which
>> it would need to do to be of any use?
>
> Various commands set the mark, as documented in the manual.  When you
> use them, normally a message appears in the echo area saying "Mark
> set".

Yes, and they never told me anything because I don't use the mark for
navigation.  When I want a region, i. e. a selection, I go where I want
it and select what I want.  The mark is irrelevant with this kind of
usage, and so are these messages.

> The mark is a standard Emacs marker, as described in (info
> "(elisp) Markers"):
>
>     A “marker” is a Lisp object used to specify a position in a buffer
>     relative to the surrounding text.  A marker changes its offset from the
>     beginning of the buffer automatically whenever text is inserted or
>     deleted, so that it stays with the two characters on either side of it.

And there is no way to show the mark?

>> >> What would the advantage of hidden regions be?  When something is within
>> >> a region, it should be highlighted, and when it is no longer
>> >> highlighted, it should no longer be within a region.
>> >
>> > Again, in Emacs, as long there is a mark in the current buffer, there
>> > is always a "region".
>> 
>> How would that make sense?  I expect the mark to be gone once I used the
>> region.
>
> That's what transient-mark-mode tries to implement, I think.

It doesn't remove the mark after a highlighted region has been used.
The idea was apparently to limit functions to a selection by
highlighting a region and then calling it particularly "active".

Highlighting and calling a region "active" would not be necessary if
functions could otherwise be limited to the region.  Combining these
three things and not allowing another way to limit functions to the
region make a mess.

>> > The user might want it highlighted for various reasons, possibly not
>> > covered by the current implementation, where Emacs highlights the
>> > region only when 'mark-active' is non-nil.
>> 
>> Yes, and that leads to misunderstandings, like d-s-m.  It doesn't make
>> any sense to claim that there is a region when there is none highlighted
>> and only creates the inconsistency that an arbitrary part of a buffer
>> can be deleted or copied, accidentally or intentionally, i. e. that
>> something can be done with a region while the region is not active and
>> nothing should possibly be done with it.
>
> Again, that seems like the intention behind transient-mark-mode.  But
> the implementation is, then, in a way incomplete: C-w still kills the
> region, no matter whether it is active or not, in transient-mark-mode.

Yes, it is an inconsistency.

>> >> Are these hidden regions a remnant of technical limitations that made it
>> >> advisable not to highlight the selection?
>> >
>> > No, they stem from convenience.  For example, typing C-M-a in a source
>> 
>> That key binding only works when you can use Alt instead of ESC.
>
> Does ESC C-a not work for you?  Or C-[ C-a?

ESC C-a works.  [ is on AltGr+8.

Emacs would have to have all key bindings re-defined to work well with
keyboards for different languages, leading to a definition for each
language.

> [...]
>> > Highlighting the region at any of these steps might be helpful for the
>> > user, but Emacs can't know exactly when -- which is one argument for
>> > allowing to toggle the highlighting dynamically as necessary,
>> > independently of whether the mark is ever "active".
>> 
>> This is a problem of navigating source code (or other files) and has
>> nothing to do with regions or highlighting.
>> 
>> Or what has navigating between a current location and the beginning of a
>> function to do with selecting and highlighting parts of the contents of
>> a buffer in order to copy or to delete them, or to do something with
>> them like query-replace?
>
> The places where the mark has been set are places of interest to the
> user for some reason or another -- that's all.

The only purpose of the mark is to make a selection.  After the
selection has been used, editing moves on, and the location has become
irrelevant.  Places of interest are those where navigational aids are
being placed, like bookmarks and registers.

If it was possible to make a selection without using the mark, I might
never use the mark.  However, I might get used to using the mark for
navigation if it was like a default register that can be easily set and
moved back to. The way it currently is is merely dangerous because it
may influence hidden and highlighted regions without that being my
intention.

>> > As seen above, use of C-u C-SPC effectively restores the region at
>> > some previous point in editing.
>> 
>> That I move around in a file as I see fit while reading or editing it
>> doesn't have anything to do with regions I might select to do something
>> with.  I might highlight a selection to make parts of source code stick
>> out as a reminder because they need to be fixed or worked upon in some
>> particular order.  I could use registers and/or bookmarks instead, but
>> it would be much more convenient to use highlighting and perhaps to be
>> able to jump through the selections.
>
> This would be a good use case for registers storing regions, I think.
> The mark ring is a useful tool, but it does not give easy, random
> access to all previous selections.  We need a bug report for this.

A feature request for the possibility of having multiple regions that
can be highlighted, first decoupling making selections from navigation,
might be an option.  I'm not sure if further discussion before making
such a request is better because there might be pretty strong resistance
against this from everyone used to and using things the way they have
been for a long time --- and maybe we're missing something.

>> The mark is only for setting the begin of a selection, nothing else.  I
>> expect it to be gone once I did something with the selection.
>> 
>> It doesn't even matter to me if there is a mark.  All I do is start
>> selecting somewhere and when it's selected, I do something with it, and
>> that's all there is to it.
>> 
>> Don't mix up a mark for navigational purposes with making and
>> highlighting selections.
>
> It's probably feasible to add a "type" field to the mark, indicating
> where it came from (i.e., if it was set explicitly by the user, by a
> certain command, from a mouse selection, ...).  Then we could offer
> commands that jump between previous selections, or between previous
> marks set by the user for navigation.

Why not let the mark be mark and find a way of making selections
independently from it?

Some people like to make shift-selections.  They could be independent
from the mark stuff and simply allow to make selections something can be
done with.

>> > Working on a specific region can often be done conveniently from an
>> > indirect buffer, as in the earlier example.
>> 
>> It's quite inconvenient because with that, the source tends to occupy
>> both frames I have on screen because I'd narrow the indirect buffer to
>> what I'm working on --- which is already another inconvenience --- and
>> need the other frame to look up things I can't see in the indirect
>> buffer because it's narrowed.  I've given up on it, it's just too
>> awkward.
>> 
>> As for doing other things, like replacing text in multiple parts of a
>> buffer, is that something that could be usefully done with indirect
>> buffers?  With multiple regions, I'd highlight some parts of the buffer,
>> do the replacement limited to these parts and would be done with it.
>> I'd be able to see all of the buffer while doing this.
>
> Not possible yet, I think (at least, without making N indirect buffers
> for the N regions and running the replacement command in all of them).

Yes, that's what I thought, I'd have to make many indirect buffers.

> But if we had some way to record the "type" of a previous mark (as
> above), then we could offer a command to replace, for example, the
> last N "active regions" in the buffer.  I think that might fit the
> bill.

That would overload the mark even more than it already is.

>> Indirect buffers still hold all of the text, so instead of marking what
>> I want to work with, I'd have to narrow out what I'm not working with,
>> and IIRC, it's not possible to narrow a buffer "the other way round" so
>> that the parts I want to work with remain and all the rest of the buffer
>> is narrowed away.
>
> I don't think that's possible yet.

Having multiple regions active would make this unnecessary :)

Re: visual-region-mode?

[Alan Mackenzie]

Hello, hw.

On Thu, Sep 13, 2018 at 06:00:32 +0200, hw wrote:
> charles@aurox.ch (Charles A. Roelli) writes:

> >> From: hw <hw@adminart.net>
> >> Date: Tue, 11 Sep 2018 23:56:11 +0200

> >> [...]

> > This is where Emacs differs from other programs, I suppose.  It's
> > optimized for efficient use, even when the result can be a surprise to
> > the user.  Otherwise, in this case, C-w and M-w would do nothing with
> > no "active region".

> What is efficient about hidden regions the way they are?

They don't get in your way.  A lot of the time, you won't be
conceptualising the buffer portion between mark and point as "the
region" - it's just point, and there's mark hanging around somewhere,
possibly at somewhere significant.

I think at some stage somebody tried having the region constantly
highlighted, and it proved annoying, with the highlighting continually
moving as you type stuff in, or even just move point.

> If killing or copying a region didn't happen to be bound to keys that
> are rather unlikely to get pressed by mistake, the design flaw of being
> able to do something with a non-highlighted region while
> transient-mark-mode is enabled might be more obvious.

What seems like a design flaw to you is a feature to somebody else.
That's why Emacs is so customisable.  As Juri has already pointed out,
there's an option you can set so that this "design flaw" won't affect
you.  I suggest you spending a couple of hours reading through the
chapter "The Mark and the Region" (also known simply as "Mark") in the
Emacs manual to see if there're any other options which would be useful
to you at a non-default setting.

> Disabling transient-mark-mode removes the possibility of highlighting
> regions.  What is the purpose of that?

For users who find this highlighting unhelpful.  As stated above, it was
found in the distant past that constantly highlighting the region was
counter-productive.  If you disagree with that, then implement an option
to have such highlighting.  If you genuinely find it useful, then ask for
your new option to be incorporated into the Emacs master.  You might be
surprised just how open the project leadership is to such innovations.

> >> > C-SPC (without a prefix argument) always pushes a mark, so it always
> >> > alters the region (unless point is already at the mark).  C-u C-SPC
> >> > sets point where the mark is, and pops the mark ring, effectively
> >> > restoring the previous region.  We should keep this behavior.

> >> How am I supposed to know where a mark was?  Why would I try to confuse
> >> myself with C-u C-spc?  In which way is the position of the mark
> >> adjusted so that it sticks with the same contents of the buffer, which
> >> it would need to do to be of any use?

Mark does get adjusted so that it stays at the "same" position in the
buffer, even if you insert or delete text before it.  Try it!

> > Various commands set the mark, as documented in the manual.  When you
> > use them, normally a message appears in the echo area saying "Mark
> > set".

> Yes, and they never told me anything because I don't use the mark for
> navigation.

An interesting question: why not?  The mark is one of the concepts which
distinguish Emacs from lesser editors, and with it you can do things
like:
(i) You search for something, and find it.  You want to go back to your
starting point.  No problem in Emacs!  C-u C-<space>.
(ii) You're editing something, and you want to read the massive comment
that often appears near the beginning of source files.  You do M-<, read
that comment, then C-u C-<space> to get back to where you were editing.

Personally, I use the mark all the time for navigation, and would not
want to go back to an editor without one.

> When I want a region, i. e. a selection, I go where I want it and
> select what I want.  The mark is irrelevant with this kind of usage,
> and so are these messages.

You can ignore both of them, surely, for this kind of usage.

[ .... ]

> And there is no way to show the mark?

Not really, no.  Highlighting the region when transient-mark-mode is
enabled is sort of a way, but that's not really what you meant.

When I use the mark, my subconsciousness retains a map of where the mark
is for an appreciable time.  I don't need the mark to be visible.  I
don't think most users do, either.

If you want the mark to be visible, implement it.  Others might find it
useful, too.

> >> >> What would the advantage of hidden regions be?  When something is within
> >> >> a region, it should be highlighted, and when it is no longer
> >> >> highlighted, it should no longer be within a region.

> >> > Again, in Emacs, as long there is a mark in the current buffer, there
> >> > is always a "region".

> >> How would that make sense?  I expect the mark to be gone once I used the
> >> region.

> > That's what transient-mark-mode tries to implement, I think.

> It doesn't remove the mark after a highlighted region has been used.
> The idea was apparently to limit functions to a selection by
> highlighting a region and then calling it particularly "active".

> Highlighting and calling a region "active" would not be necessary if
> functions could otherwise be limited to the region.  Combining these
> three things and not allowing another way to limit functions to the
> region make a mess.

There is another way: narrow to the region (e.g. with C-x n n).  Standard
editing function are then restricted to this portion of the buffer.
Useful here is, for example, C-x n d, which narrows to the current
source-code function.

[ .... ]

> Emacs would have to have all key bindings re-defined to work well with
> keyboards for different languages, leading to a definition for each
> language.

That's a bit of an exaggeration.

[ .... ]

> The only purpose of the mark is to make a selection.

No.  That's how _your_ use of it is currently restricted.  I earnestly
recommend you to spend time learning other uses of the mark.  It will
ease your editing.

> After the selection has been used, editing moves on, and the location
> has become irrelevant.  Places of interest are those where navigational
> aids are being placed, like bookmarks and registers.

> If it was possible to make a selection without using the mark, I might
> never use the mark.  However, I might get used to using the mark for
> navigation if it was like a default register that can be easily set and
> moved back to. The way it currently is is merely dangerous because it
> may influence hidden and highlighted regions without that being my
> intention.

Repeat: in an Emacs buffer there is exactly one region at any time.  I
can't suppress the feeling that sometime soon, something in your brain is
going to click, you're going to shout "Eureka!", and suddenly the Emacs
mark will be obvious and natural to you (as it is to so many users).

[ .... ]

> A feature request for the possibility of having multiple regions that
> can be highlighted, first decoupling making selections from navigation,
> might be an option.  I'm not sure if further discussion before making
> such a request is better because there might be pretty strong resistance
> against this from everyone used to and using things the way they have
> been for a long time --- and maybe we're missing something.

There would indeed be resistance.  Somehow, you've got to set up a
multiple region.  That will need key sequences (of which there are very
few spare).  Then you've got to modify lots of commands to work on a
multiple region.  Indeed you've got to decide what they will do.  This is
not a task for the faint-hearted.

[ .... ]

> Why not let the mark be mark and find a way of making selections
> independently from it?

Because that would lead to a general loss of convenience in the use of
the mark.  Still, if you have a solid idea of how this could work (and it
would have to be optional), implement it and ask for it to be
incorporated into Emacs.

[ .... ]

> That would overload the mark even more than it already is.

I don't agree the mark is overloaded.  Using it's several features
together is one of the delights of Emacs.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: visual-region-mode?

[hw]

Alan Mackenzie <acm@muc.de> writes:

> Hello, hw.
>
> On Thu, Sep 13, 2018 at 06:00:32 +0200, hw wrote:
>> charles@aurox.ch (Charles A. Roelli) writes:
>
>> >> From: hw <hw@adminart.net>
>> >> Date: Tue, 11 Sep 2018 23:56:11 +0200
>
>> >> [...]
>
>> > This is where Emacs differs from other programs, I suppose.  It's
>> > optimized for efficient use, even when the result can be a surprise to
>> > the user.  Otherwise, in this case, C-w and M-w would do nothing with
>> > no "active region".
>
>> What is efficient about hidden regions the way they are?
>
> They don't get in your way.

Of course they do.  They're lurking hidden in the background, waiting
for me to make a mistake, and are making me feel uneasy all the time.

> A lot of the time, you won't be conceptualising the buffer portion
> between mark and point as "the region" - it's just point, and there's
> mark hanging around somewhere, possibly at somewhere significant.

I always know it's lurking.

> [...]
>> If killing or copying a region didn't happen to be bound to keys that
>> are rather unlikely to get pressed by mistake, the design flaw of being
>> able to do something with a non-highlighted region while
>> transient-mark-mode is enabled might be more obvious.
>
> What seems like a design flaw to you is a feature to somebody else.

No, software has a design flaw when it doesn't protect the user from
making mistakes and makes mistakes even worse.  For that, it doesn't
matter how easy it is to make the mistake.  This doesn't have anything
to do with features.

> That's why Emacs is so customisable.  As Juri has already pointed out,
> there's an option you can set so that this "design flaw" won't affect
> you.  I suggest you spending a couple of hours reading through the
> chapter "The Mark and the Region" (also known simply as "Mark") in the
> Emacs manual to see if there're any other options which would be useful
> to you at a non-default setting.

I already looked in the manual and was surprised about the lack of
options.  Maybe I'll find some when I read more.

>> Disabling transient-mark-mode removes the possibility of highlighting
>> regions.  What is the purpose of that?
>
> For users who find this highlighting unhelpful.

That simply doesn't make any sense.

> [...]
>
>> >> > C-SPC (without a prefix argument) always pushes a mark, so it always
>> >> > alters the region (unless point is already at the mark).  C-u C-SPC
>> >> > sets point where the mark is, and pops the mark ring, effectively
>> >> > restoring the previous region.  We should keep this behavior.
>
>> >> How am I supposed to know where a mark was?  Why would I try to confuse
>> >> myself with C-u C-spc?  In which way is the position of the mark
>> >> adjusted so that it sticks with the same contents of the buffer, which
>> >> it would need to do to be of any use?
>
> Mark does get adjusted so that it stays at the "same" position in the
> buffer, even if you insert or delete text before it.  Try it!

And how do I know where it is?  And why text before it and not after it?
When you set a mark in the middle of the buffer and delete something at
the end, the mark moves towards the end of the buffer.  And what happens
when you delete a place that contains a mark?

>> > Various commands set the mark, as documented in the manual.  When you
>> > use them, normally a message appears in the echo area saying "Mark
>> > set".
>
>> Yes, and they never told me anything because I don't use the mark for
>> navigation.
>
> An interesting question: why not?  The mark is one of the concepts which
> distinguish Emacs from lesser editors, and with it you can do things
> like:
> (i) You search for something, and find it.  You want to go back to your
> starting point.  No problem in Emacs!  C-u C-<space>.
> (ii) You're editing something, and you want to read the massive comment
> that often appears near the beginning of source files.  You do M-<, read
> that comment, then C-u C-<space> to get back to where you were editing.
>
> Personally, I use the mark all the time for navigation, and would not
> want to go back to an editor without one.

The mark is not for navigation, it's for making selections.  When I want
to select something, I go there and select it.  So why would these
messages tell me anything and why would I care?  I don't even need a
mark, I only need to select things.

>> When I want a region, i. e. a selection, I go where I want it and
>> select what I want.  The mark is irrelevant with this kind of usage,
>> and so are these messages.
>
> You can ignore both of them, surely, for this kind of usage.

No, the problem is that there is always something lurking hidden in the
background --- you call it a region.  If I was ignoring that, I might
make a mistake and do something with it I don't want to.

> [ .... ]
>
>> And there is no way to show the mark?
>
> Not really, no.  Highlighting the region when transient-mark-mode is
> enabled is sort of a way, but that's not really what you meant.
>
> When I use the mark, my subconsciousness retains a map of where the mark
> is for an appreciable time.  I don't need the mark to be visible.  I
> don't think most users do, either.
>
> If you want the mark to be visible, implement it.  Others might find it
> useful, too.

I don't know how to.  I might find it useful to use a mark for
navigation, but only when has nothing to do with making selections.

>> >> >> What would the advantage of hidden regions be?  When something is within
>> >> >> a region, it should be highlighted, and when it is no longer
>> >> >> highlighted, it should no longer be within a region.
>
>> >> > Again, in Emacs, as long there is a mark in the current buffer, there
>> >> > is always a "region".
>
>> >> How would that make sense?  I expect the mark to be gone once I used the
>> >> region.
>
>> > That's what transient-mark-mode tries to implement, I think.
>
>> It doesn't remove the mark after a highlighted region has been used.
>> The idea was apparently to limit functions to a selection by
>> highlighting a region and then calling it particularly "active".
>
>> Highlighting and calling a region "active" would not be necessary if
>> functions could otherwise be limited to the region.  Combining these
>> three things and not allowing another way to limit functions to the
>> region make a mess.
>
> There is another way: narrow to the region (e.g. with C-x n n).  Standard
> editing function are then restricted to this portion of the buffer.

That is triple work because first I'd have to make a selection, second
I'd have to narrow the buffer and third I'd have to widen it again.

> Useful here is, for example, C-x n d, which narrows to the current
> source-code function.

Cases in which operations that need to be limited to a selection are as
wide as a whole function almost don't exist.

> [ .... ]
>
>> Emacs would have to have all key bindings re-defined to work well with
>> keyboards for different languages, leading to a definition for each
>> language.
>
> That's a bit of an exaggeration.

Why?  Move one key binding, and there will already be another key
binding in the way, so you first have to move that one, etc., and you
end up shuffling them all around a great deal until you might find
something that reasonably works --- or not.

> [ .... ]
>
>> The only purpose of the mark is to make a selection.
>
> No.  That's how _your_ use of it is currently restricted.  I earnestly
> recommend you to spend time learning other uses of the mark.  It will
> ease your editing.

I don't have any other uses for it --- actually, I don't have any.
Making selections doesn't have anything to do with navigation, and
overloading the navigational aid that is called a mark by involving it
into making selections is a very bad idea.  A constantly changing,
hidden selection which is being brought up by that is also a very bad
idea.

>> After the selection has been used, editing moves on, and the location
>> has become irrelevant.  Places of interest are those where navigational
>> aids are being placed, like bookmarks and registers.
>
>> If it was possible to make a selection without using the mark, I might
>> never use the mark.  However, I might get used to using the mark for
>> navigation if it was like a default register that can be easily set and
>> moved back to. The way it currently is is merely dangerous because it
>> may influence hidden and highlighted regions without that being my
>> intention.
>
> Repeat: in an Emacs buffer there is exactly one region at any time.  I
> can't suppress the feeling that sometime soon, something in your brain is
> going to click, you're going to shout "Eureka!", and suddenly the Emacs
> mark will be obvious and natural to you (as it is to so many users).

I might use it for navigation if it didn't do anything else.  Since
there is currently no other way to make a selection, I have to use it
for making selections.  There's nothing obvious about it other than that
it is a bad idea.

> [ .... ]
>
>> A feature request for the possibility of having multiple regions that
>> can be highlighted, first decoupling making selections from navigation,
>> might be an option.  I'm not sure if further discussion before making
>> such a request is better because there might be pretty strong resistance
>> against this from everyone used to and using things the way they have
>> been for a long time --- and maybe we're missing something.
>
> There would indeed be resistance.  Somehow, you've got to set up a
> multiple region.  That will need key sequences (of which there are very
> few spare).  Then you've got to modify lots of commands to work on a
> multiple region.  Indeed you've got to decide what they will do.  This is
> not a task for the faint-hearted.

Apparently there are some modes that allow to use multiple selections :)

>
> [ .... ]
>
>> Why not let the mark be mark and find a way of making selections
>> independently from it?
>
> Because that would lead to a general loss of convenience in the use of
> the mark.

It could be used for navigation, how would that make anything less
convenient?

> Still, if you have a solid idea of how this could work (and it
> would have to be optional), implement it and ask for it to be
> incorporated into Emacs.

I don't know how to implement it.

> [ .... ]
>
>> That would overload the mark even more than it already is.
>
> I don't agree the mark is overloaded.  Using it's several features
> together is one of the delights of Emacs.

It's no delight at all, it's a bad idea.

Re: visual-region-mode?

[Charles A. Roelli]

> From: hw <hw@adminart.net>
> Date: Thu, 13 Sep 2018 06:00:32 +0200
>
> What is efficient about hidden regions the way they are?

The region has a simple definition, and the commands using the region
are well-marked (e.g. "kill-region", "fill-region", "eval-region",
...).

> 	       When I want a region, i. e. a selection, I go where I want
> it and select what I want.

No need, you have the mark already. ;)

> And there is no way to show the mark?

Besides the ways already mentioned, no.  As Alan has suggested, it
becomes second nature to keep its position in your head.  And if you
want to know how far away it is from point (as a reminder), there is
the key M-= (or ESC =).

> The only purpose of the mark is to make a selection.  After the
> selection has been used, editing moves on, and the location has become
> irrelevant.

Sometimes yes, sometimes no.  Better to err on the side of caution,
than to forget all previous marks (as other programs do).

> >> That I move around in a file as I see fit while reading or editing it
> >> doesn't have anything to do with regions I might select to do something
> >> with.  I might highlight a selection to make parts of source code stick
> >> out as a reminder because they need to be fixed or worked upon in some
> >> particular order.  I could use registers and/or bookmarks instead, but
> >> it would be much more convenient to use highlighting and perhaps to be
> >> able to jump through the selections.
> >
> > This would be a good use case for registers storing regions, I think.
> > The mark ring is a useful tool, but it does not give easy, random
> > access to all previous selections.  We need a bug report for this.
> 
> A feature request for the possibility of having multiple regions that
> can be highlighted, first decoupling making selections from navigation,
> might be an option.  I'm not sure if further discussion before making
> such a request is better because there might be pretty strong resistance
> against this from everyone used to and using things the way they have
> been for a long time --- and maybe we're missing something.

I make a less ambitious suggestion: get registers to store regions
(i.e., two markers).  Then we can add functions to highlight them, set
one of them as the "active region", and otherwise operate on them,
either individually or as a set -- a bit like the "zones" Drew has
detailed.

Re: visual-region-mode?

[hw]

charles@aurox.ch (Charles A. Roelli) writes:

>> From: hw <hw@adminart.net>
>> Date: Thu, 13 Sep 2018 06:00:32 +0200
>>
>> What is efficient about hidden regions the way they are?
>
> The region has a simple definition,

Someone already pointed out that the definition isn't all that simple.

> and the commands using the region
> are well-marked (e.g. "kill-region", "fill-region", "eval-region",
> ...).

How does this make hidden regions efficient?

>> 	       When I want a region, i. e. a selection, I go where I want
>> it and select what I want.
>
> No need, you have the mark already. ;)

No, I don't.  What I select doesn't have anything to do with this mark.

>> And there is no way to show the mark?
>
> Besides the ways already mentioned, no.  As Alan has suggested, it
> becomes second nature to keep its position in your head.  And if you
> want to know how far away it is from point (as a reminder), there is
> the key M-= (or ESC =).

Sure, I'm going to remember the positions of marks in the 25 buffers or
so I have open at work in the main Emacs session over months, plus the
other 5 or 10 in every minor Emacs session plus the ones I have at home
--- as if I had nothing better to do than to burden me with irrelevant
stuff like that.

I'm simply not using the mark, and it shouldn't be there.  The hidden
regions they create are a source for errors.  Make it so they don't
create regions, and the mark might become usable, provided it can be
made visible.

>> The only purpose of the mark is to make a selection.  After the
>> selection has been used, editing moves on, and the location has become
>> irrelevant.
>
> Sometimes yes, sometimes no.  Better to err on the side of caution,
> than to forget all previous marks (as other programs do).

Wrong, leaving the mark lurking around to create a hidden region only
means to make mistakes a user might make much worse.  It is a design
flaw.

> [...]
>> > This would be a good use case for registers storing regions, I think.
>> > The mark ring is a useful tool, but it does not give easy, random
>> > access to all previous selections.  We need a bug report for this.
>> 
>> A feature request for the possibility of having multiple regions that
>> can be highlighted, first decoupling making selections from navigation,
>> might be an option.  I'm not sure if further discussion before making
>> such a request is better because there might be pretty strong resistance
>> against this from everyone used to and using things the way they have
>> been for a long time --- and maybe we're missing something.
>
> I make a less ambitious suggestion: get registers to store regions
> (i.e., two markers).  Then we can add functions to highlight them, set
> one of them as the "active region", and otherwise operate on them,
> either individually or as a set -- a bit like the "zones" Drew has
> detailed.

Maybe it's better not to use "regions" but "selections".
Transient-mark-mode already shows that people don't care about regions
but about visible selections.

How multiple selections would be implemented wasn't my concern, though.
I wouldn't know the best way how to technically do that.

Re: visual-region-mode?

[Charles A. Roelli]

> From: hw <hw@adminart.net>
> Date: Sat, 15 Sep 2018 21:21:30 +0200
> 
> > and the commands using the region
> > are well-marked (e.g. "kill-region", "fill-region", "eval-region",
> > ...).
> 
> How does this make hidden regions efficient?

You have a clear set of actions that can work on the region, anytime,
no matter whether the region is "hidden", or active and visible, or
rectangular.
 
> I'm simply not using the mark, and it shouldn't be there.  The hidden
> regions they create are a source for errors.  Make it so they don't
> create regions, and the mark might become usable, provided it can be
> made visible.

The "hidden regions" can only be a source of error if you type, say,
C-w or M-w at random during editing.  I don't understand why you would
do that, especially in your case if you haven't selected a region
beforehand.  You could just as well have hit C-/ or C-k, which will
also change your buffer.

Re: visual-region-mode?

[hw]

charles@aurox.ch (Charles A. Roelli) writes:

>> From: hw <hw@adminart.net>
>> Date: Sat, 15 Sep 2018 21:21:30 +0200
>> 
>> > and the commands using the region
>> > are well-marked (e.g. "kill-region", "fill-region", "eval-region",
>> > ...).
>> 
>> How does this make hidden regions efficient?
>
> You have a clear set of actions that can work on the region, anytime,
> no matter whether the region is "hidden", or active and visible, or
> rectangular.

Having clarified which operations can be used with a region doesn't mean
that working with a region can be efficiently done.

In practise, there is no clear set of operations for regions.  Various
modes and their options, combined with inconsistencies and weirdness,
make it anything but clear what does what under which circumstances.

>> I'm simply not using the mark, and it shouldn't be there.  The hidden
>> regions they create are a source for errors.  Make it so they don't
>> create regions, and the mark might become usable, provided it can be
>> made visible.
>
> The "hidden regions" can only be a source of error if you type, say,
> C-w or M-w at random during editing.

What about upcase-region, downcase-region and others that don't come to
mind atm?  They already clash with transient-mark-mode and are as unsafe
as C-w and M-w.  Changing mark-even-if-inactive to nil is required to
prevent that --- why isn't that the default?

> I don't understand why you would do that,

Yes, I wouldn't do that intentionally.  That these things happen
unintentionally is, as I said before, rather unlikely.

The hidden regions mean that I always have to consider that they are
always there so that I do not make a mistake in the first place.  That
makes me feel uneasy.

It's like having to walk around with a loaded gun all the time: I
wouldn't intentionally shoot my feet, and I wouldn't be the first one to
accidentally shoot myself if I did.  It's just easier to put the gun
away and to only get it when I want to use it than it is to exercise
perfect gun handling all the time.

Do you carry a toolbox around all the time because you are a mechanic,
or do you leave it at home when you go to a party where you won't need
it?  Emacs drags it around to every party because it doesn't know how to
let go.  If you ask Emacs about it, it'll say it's because it's
fundamental.  It can be difficult to argue with fundamental.

> especially in your case if you haven't selected a region beforehand.

You don't need to make a selection for a region you could make a mistake
with to always exist once there is a mark somewhere in the buffer.  That
region always exists all by itself, fundamentally waiting for you to
eventually make your mistake.

> You could just as well have hit C-/ or C-k, which will also change
> your buffer.

Yes, there are mistakes users can make the software can not reasonably
protect them against.  That doesn't mean the software shouldn't protect
the users when protecting them is reasonably possible.  It also doesn't
mean the software should make the mistake worse.

RE: visual-region-mode?

[Drew Adams]

> The hidden regions mean that I always have to consider that they are
> always there so that I do not make a mistake in the first place.  That
> makes me feel uneasy.

To be clear:

1. There is only ever one region per buffer - not regions.

2. Wrt "hidden": The cursor is the point end of the region. It, at least, is always visible, never hidden. The region might not be highlighted, but its text is typically not hidden (invisible).

So it would be more accurate for you to speak of the region (singular) not being _highlighted_.

Re: visual-region-mode?

[hw]

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

>> The hidden regions mean that I always have to consider that they are
>> always there so that I do not make a mistake in the first place.  That
>> makes me feel uneasy.
>
> To be clear:
>
> 1. There is only ever one region per buffer - not regions.
>
> 2. Wrt "hidden": The cursor is the point end of the region. It, at
> least, is always visible, never hidden. The region might not be
> highlighted, but its text is typically not hidden (invisible).
>
> So it would be more accurate for you to speak of the region (singular) not being _highlighted_.

At least the beginning of the region can be hidden (not on display).
The mark is always hidden (invisible).

The mark being invisible and the region not highlighted make the region
hidden (I can't see what it contains and not really where it is.).

That point "marks" the end of the region is an irrelevant technicality,
and that point always drags an invisible (imaginary) tail either in
front of it or behind it is confusing.  It does not contribute to making
the region unhidden.  Of course, I could use point to imagine something,
but I don't want to.

The region is just something "hidden", one for each buffer or window,
unless highlighted.  Being more accurate about it doesn't make me feel
less uneasy about it.


I still don't understand why the selection (not the region) can not be
highlighted when transient-mark-mode is disabled and why the mark can
not be indicated.

Since we are at it, why doesn't point at least indicate in which
direction the imaginary tail goes?

Re: visual-region-mode?

[Juri Linkov]

> The region is just something "hidden", one for each buffer or window,
> unless highlighted.  Being more accurate about it doesn't make me feel
> less uneasy about it.

I'm not sure what is worse: "hidden region" or "hidden selection".

What you call "hidden region" is undoubtedly dangerous: when you forget
you had a mark in the buffer and accidentally call a disastrous command
like C-w whose catastrophic consequences may go unnoticed.  This happens
when the region is not highlighted, so you don't see it.

But "hidden selection" that you proposed has the same flaw: when
you create a permanent selection, and move point to another part of
the buffer, so the selection scrolls off-screen, you don't see it anymore,
and might forget it's still active somewhere in the buffer, then
accidentally typing C-w will have the same consequences as in case
of "hidden region".

Re: visual-region-mode?

[Eli Zaretskii]

> From: hw <hw@adminart.net>
> Date: Tue, 18 Sep 2018 01:11:47 +0200
> Cc: lokedhs@gmail.com, cpitclaudel@gmail.com, charles@aurox.ch, rms@gnu.org,
> 	emacs-devel@gnu.org
> 
> Since we are at it, why doesn't point at least indicate in which
> direction the imaginary tail goes?

Because no one has written code to do that, of course.

Re: visual-region-mode?

[Charles A. Roelli]

> From: hw <hw@adminart.net>
> Date: Mon, 17 Sep 2018 22:36:30 +0200
>
> Having clarified which operations can be used with a region doesn't mean
> that working with a region can be efficiently done.

It does for me.  For example, see the output of M-x -region TAB.  By
just knowing a smidgeon of these commands, you can work very
efficiently with a region, with all the documentation and help Emacs
provides.  If we somehow "disarm" the region by default (as you have
suggested), the use of all these commands would be less efficient.

> > The "hidden regions" can only be a source of error if you type, say,
> > C-w or M-w at random during editing.
> 
> What about upcase-region, downcase-region and others that don't come to
> mind atm?  They already clash with transient-mark-mode and are as unsafe
> as C-w and M-w.  Changing mark-even-if-inactive to nil is required to
> prevent that --- why isn't that the default?

These commands are already disabled by default.

> The hidden regions mean that I always have to consider that they are
> always there so that I do not make a mistake in the first place.  That
> makes me feel uneasy.

What's the worst that could happen?  We have so many ways to recover
from these sorts of errors: autosaves, backups, VC,
diff-buffer-with-file, ...

In addition, for buffers that you think should have additional
protection against accidental edits, there's "view-mode".

Re: visual-region-mode?

[hw]

charles@aurox.ch (Charles A. Roelli) writes:

>> From: hw <hw@adminart.net>
>> Date: Mon, 17 Sep 2018 22:36:30 +0200
>>
>> Having clarified which operations can be used with a region doesn't mean
>> that working with a region can be efficiently done.
>
> It does for me.  For example, see the output of M-x -region TAB.  By
> just knowing a smidgeon of these commands, you can work very
> efficiently with a region, with all the documentation and help Emacs
> provides.

That's like saying it doesn't matter how inefficient a procedure is if
you only have some instructions to perform it.

> If we somehow "disarm" the region by default (as you have
> suggested), the use of all these commands would be less efficient.

That was Elis idea, and it doesn't refer to commands implying "region"
but, IIUC, to how to deal with that users might sometimes want to delete
a region by inserting characters and sometimes not.

>> > The "hidden regions" can only be a source of error if you type, say,
>> > C-w or M-w at random during editing.
>> 
>> What about upcase-region, downcase-region and others that don't come to
>> mind atm?  They already clash with transient-mark-mode and are as unsafe
>> as C-w and M-w.  Changing mark-even-if-inactive to nil is required to
>> prevent that --- why isn't that the default?
>
> These commands are already disabled by default.

Right, I didn't notice.  Emacs says they are disabled because they can
be confusing.  Confusing usually doesn't exactly mean efficient.

>> The hidden regions mean that I always have to consider that they are
>> always there so that I do not make a mistake in the first place.  That
>> makes me feel uneasy.
>
> What's the worst that could happen?  We have so many ways to recover
> from these sorts of errors: autosaves, backups, VC,
> diff-buffer-with-file, ...

An accidental downcase-region of a couple lines in a program usually
isn't very noticeable unless you look very closely at it, so chances
aren't too bad that the problems they may cause only come up when it
means that the worst thing does happen.

> In addition, for buffers that you think should have additional
> protection against accidental edits, there's "view-mode".

Well, I have delete-active-region and mark-even-if-inactive set to nil
and am testing this:


(defun my-exchange-point-and-mark (&optional arg)
  "Put the mark where point is now, and point where the mark is
now.  With a prefix argument, toggle the activeness of the
region.

This function itself is ignorant of `transient-mark-mode'."
  (interactive "P")
  (let ((omark (marker-position (mark-marker))))
    (if (null omark)
        (user-error "No mark set in this buffer"))
    (set-marker (mark-marker) (point))
    (goto-char omark))
  (if arg
      (if mark-active (deactivate-mark)
	(activate-mark t))))


Now I have the region fortified and am able to use the mark for
navigation without making (or unmaking) a selection from the region
unless I actually want to.  I just wish the mark was visible and point
was indicating the direction of it.

View-mode is cool for things not being edited.

Re: visual-region-mode?

[Charles A. Roelli]

> From: hw <hw@adminart.net>
> Date: Wed, 19 Sep 2018 03:45:23 +0200
>
> >> Having clarified which operations can be used with a region doesn't mean
> >> that working with a region can be efficiently done.
> >
> > It does for me.  For example, see the output of M-x -region TAB.  By
> > just knowing a smidgeon of these commands, you can work very
> > efficiently with a region, with all the documentation and help Emacs
> > provides.
> 
> That's like saying it doesn't matter how inefficient a procedure is if
> you only have some instructions to perform it.

When these instructions are so simple, they cannot help being
efficient.  But if you reject the main building block they use (the
region, active or not), then it makes sense that you find them
inefficient.

> > If we somehow "disarm" the region by default (as you have
> > suggested), the use of all these commands would be less efficient.
> 
> That was Elis idea, and it doesn't refer to commands implying "region"
> but, IIUC, to how to deal with that users might sometimes want to delete
> a region by inserting characters and sometimes not.

Ok.

> Well, I have delete-active-region and mark-even-if-inactive set to nil
> and am testing this:
> 
> 
> (defun my-exchange-point-and-mark (&optional arg)
>   "Put the mark where point is now, and point where the mark is
> now.  With a prefix argument, toggle the activeness of the
> region.
> 
> This function itself is ignorant of `transient-mark-mode'."
>   (interactive "P")
>   (let ((omark (marker-position (mark-marker))))
>     (if (null omark)
>         (user-error "No mark set in this buffer"))
>     (set-marker (mark-marker) (point))
>     (goto-char omark))
>   (if arg
>       (if mark-active (deactivate-mark)
> 	(activate-mark t))))
> 
> 
> Now I have the region fortified and am able to use the mark for
> navigation without making (or unmaking) a selection from the region
> unless I actually want to.

Ok.  If you decided to turn "t-m-m" off, though, how would you use
"my-exchange-point-and-mark" to ever activate the mark again?  In
order for the region to be considered active, "t-m-m" has to enabled
(if only temporarily), hence the current wrangling in
"exchange-point-and-mark" to turn it on temporarily when the user asks
for it.

Re: visual-region-mode?

[hw]

charles@aurox.ch (Charles A. Roelli) writes:

>> From: hw <hw@adminart.net>
>> Date: Wed, 19 Sep 2018 03:45:23 +0200
>>
>> >> Having clarified which operations can be used with a region doesn't mean
>> >> that working with a region can be efficiently done.
>> >
>> > It does for me.  For example, see the output of M-x -region TAB.  By
>> > just knowing a smidgeon of these commands, you can work very
>> > efficiently with a region, with all the documentation and help Emacs
>> > provides.
>> 
>> That's like saying it doesn't matter how inefficient a procedure is if
>> you only have some instructions to perform it.
>
> When these instructions are so simple, they cannot help being
> efficient.

Simple instructions can be very inefficient, for example by leaving out
important information, by oversimplifying things or by trying to dumb
things down.  Look at the products Ubiquity makes, they are extremely
good examples for oversimplified instructions which make their otherwise
great products extremely inefficient whenever you need instructions.

Another example are simple instructions for your portable generator
which don't make it efficient to power your home (or anything else) with
it.  They would only make it obvious that the complexity or lack thereof
of instructions has nothing to do with how efficient something is.

> But if you reject the main building block they use (the
> region, active or not), then it makes sense that you find them
> inefficient.

Rejecting the region or not is entirely unrelated to that clarifying
operations to work with it doesn't magically make something efficient.
Besides, there are many examples showing that the operations aren't
clarified much.

>> > If we somehow "disarm" the region by default (as you have
>> > suggested), the use of all these commands would be less efficient.
>> 
>> That was Elis idea, and it doesn't refer to commands implying "region"
>> but, IIUC, to how to deal with that users might sometimes want to delete
>> a region by inserting characters and sometimes not.
>
> Ok.
>
>> Well, I have delete-active-region and mark-even-if-inactive set to nil
>> and am testing this:
>> 
>> 
>> (defun my-exchange-point-and-mark (&optional arg)
>>   "Put the mark where point is now, and point where the mark is
>> now.  With a prefix argument, toggle the activeness of the
>> region.
>> 
>> This function itself is ignorant of `transient-mark-mode'."
>>   (interactive "P")
>>   (let ((omark (marker-position (mark-marker))))
>>     (if (null omark)
>>         (user-error "No mark set in this buffer"))
>>     (set-marker (mark-marker) (point))
>>     (goto-char omark))
>>   (if arg
>>       (if mark-active (deactivate-mark)
>> 	(activate-mark t))))
>> 
>> 
>> Now I have the region fortified and am able to use the mark for
>> navigation without making (or unmaking) a selection from the region
>> unless I actually want to.
>
> Ok.  If you decided to turn "t-m-m" off, though, how would you use
> "my-exchange-point-and-mark" to ever activate the mark again? In
> order for the region to be considered active, "t-m-m" has to enabled
> (if only temporarily), hence the current wrangling in
> "exchange-point-and-mark" to turn it on temporarily when the user asks
> for it.

With t-m-m disabled, there is no way to fortify the region, and there is
no highlighting.  Why would I disable it?

With t-m-m disabled, the region can not be activated, so why would I try
to do that?  My function is ignorant of t-m-m anyway.

Why would I disable t-m-m only to ask to temporarily enable it?

Are there any disadvantages of having t-m-m enabled that would overcome
all the advantages of having it disabled?

Re: visual-region-mode?

[Charles A. Roelli]

> From: hw <hw@adminart.net>
> Date: Wed, 19 Sep 2018 22:04:14 +0200
> 
> Simple instructions can be very inefficient, for example by leaving out
> important information, by oversimplifying things or by trying to dumb
> things down.

Yes, though it's rare to hear such accusations against Emacs.

> With t-m-m disabled, there is no way to fortify the region, and there is
> no highlighting.  Why would I disable it?

There would be a way to "fortify" the region, if you had another
binding for toggling whether the region is active or not.

> With t-m-m disabled, the region can not be activated, so why would I try
> to do that?  My function is ignorant of t-m-m anyway.
> 
> Why would I disable t-m-m only to ask to temporarily enable it?

That's how the current implementation is designed: the region is
considered "active" when both "mark-active" is non-nil /and/ "t-m-m"
is on.  Unfortunately, the doc on this is unclear -- at least,
"mark-active" needs to clarify that its value is only taken into
account with "t-m-m" on:

    mark-active is a variable defined in ‘buffer.c’.
    Non-nil means the mark and region are currently active in this buffer.

    region-active-p is a compiled Lisp function in ‘simple.el’.
    Return non-nil if Transient Mark mode is enabled and the mark is active.

I'd like to be able to "activate" the region with "t-m-m" off to use
commands that behave differently when the region is active (like M-%),
without the highlighting that "t-m-m" forces, and without the region
randomly deactivating itself after certain commands as it does with
"t-m-m" switched on.  Highlighting the region could be a separate
mode.

> Are there any disadvantages of having t-m-m enabled that would overcome
> all the advantages of having it disabled?

Not sure I understand this.

Re: visual-region-mode?

[hw]

charles@aurox.ch (Charles A. Roelli) writes:

>> From: hw <hw@adminart.net>
>> Date: Wed, 19 Sep 2018 22:04:14 +0200
>
> [...]
>> With t-m-m disabled, there is no way to fortify the region, and there is
>> no highlighting.  Why would I disable it?
>
> There would be a way to "fortify" the region, if you had another
> binding for toggling whether the region is active or not.

Without t-m-m, the region can not become active.

>> With t-m-m disabled, the region can not be activated, so why would I try
>> to do that?  My function is ignorant of t-m-m anyway.
>> 
>> Why would I disable t-m-m only to ask to temporarily enable it?
>
> That's how the current implementation is designed: the region is
> considered "active" when both "mark-active" is non-nil /and/ "t-m-m"
> is on.

That doesn't explain why I would disable t-m-m.

> [...]
> I'd like to be able to "activate" the region with "t-m-m" off to use
> commands that behave differently when the region is active (like M-%),
> without the highlighting that "t-m-m" forces,

Perhaps there is a way to disable the highlighting.  I haven't found out
how something is highlighted.

> and without the region randomly deactivating itself after certain
> commands as it does with "t-m-m" switched on.

I've never had an issue with the region deactivating itself randomly.
Under what circumstances exactly does this happen?

Are you referring to commands deactivating the region?  That could be
configurable, though I'm not sure how useful it is to indefinitely do
something with a region until it is explicitly deactivated.  What do you
plan on doing with it that would require this?

> Highlighting the region could be a separate mode.

Highlighting the region all the time is probably not very useful.

>> Are there any disadvantages of having t-m-m enabled that would overcome
>> all the advantages of having it disabled?
>
> Not sure I understand this.

Disabling t-m-m doesn't make any sense at all.  Why would anyone disable
it?

I can see it for someone who doesn't like the highlighting, so if it was
configurable --- and it is amazing that is isn't --- whether to
highlight the region when it's active or not, everyone who dislikes the
highlighting could have t-m-m enabled.  I would remove having it
disabled entirely from Emacs because there is no point in that and only
complication.

Without highlighting, a different indicator could be useful to show
whether the region is active or not, like a hint in the mode line.

Re: visual-region-mode?

[Charles A. Roelli]

> From: hw <hw@adminart.net>
> Date: Fri, 21 Sep 2018 22:28:53 +0200
>
> > There would be a way to "fortify" the region, if you had another
> > binding for toggling whether the region is active or not.
> 
> Without t-m-m, the region can not become active.

Yes, but since we have commands that offer behavior specific to active
regions, we have the so-called "temporary transient mark mode" --
which is a hack to get around this problem.  I'd rather have a way to
explicitly activate/deactivate the region.

> >> With t-m-m disabled, the region can not be activated, so why would I try
> >> to do that?  My function is ignorant of t-m-m anyway.
> >> 
> >> Why would I disable t-m-m only to ask to temporarily enable it?
> >
> > That's how the current implementation is designed: the region is
> > considered "active" when both "mark-active" is non-nil /and/ "t-m-m"
> > is on.
> 
> That doesn't explain why I would disable t-m-m.

No, it explains why you would temporarily enable it after disabling it
permanently.

> Perhaps there is a way to disable the highlighting.  I haven't found out
> how something is highlighted.

It's possible to disable the highlighting by customizing the "region"
face.

> > and without the region randomly deactivating itself after certain
> > commands as it does with "t-m-m" switched on.
> 
> [...]
>
> Are you referring to commands deactivating the region?  

Yes.  See the doc of "t-m-m":

            The mark is "deactivated" by changing the buffer,
and after certain other operations that set the mark but whose
main purpose is something else--for example, incremental search,
M-<, and M->.

> 							  That could be
> configurable, though I'm not sure how useful it is to indefinitely do
> something with a region until it is explicitly deactivated.  

That's how the region works with "t-m-m" off: you can always invoke a
sequence of commands that use the region, without having to think
about whether it's active.  I'd like to be able to carry this behavior
over to commands that require an active region for certain things,
like M-% does for replacing inside a region.
 
> > Highlighting the region could be a separate mode.
> 
> Highlighting the region all the time is probably not very useful.

Yes, but the user knows best, IMO.  The default would still be the
same behavior as it is now.

> >> Are there any disadvantages of having t-m-m enabled that would overcome
> >> all the advantages of having it disabled?
> >
> > Not sure I understand this.
> 
> Disabling t-m-m doesn't make any sense at all.  Why would anyone disable
> it?
> 
> I can see it for someone who doesn't like the highlighting, so if it was
> configurable --- and it is amazing that is isn't --- whether to
> highlight the region when it's active or not, everyone who dislikes the
> highlighting could have t-m-m enabled.  I would remove having it
> disabled entirely from Emacs because there is no point in that and only
> complication.

I think the main point of contention is C-x C-x: it activates the mark
by default, which is irritating when you're using the mark for
navigation.  Even if you disable the highlighting of the region,
certain commands will behave differently in response to the region
being active.

You've already posted an improved version of C-x C-x that does not
activate the mark by default: I think that is the right way to go, as
well as a new command for explicitly activating/deactivating the mark.
With these two fixes, much of the contention surrounding "t-m-m"
should go.

> Without highlighting, a different indicator could be useful to show
> whether the region is active or not, like a hint in the mode line.

Yes, offering an indicator in the mode line to show whether the region
is active would be a good start.

Btw, I'm culling most of the CC list since it seems no longer relevant.

Re: visual-region-mode?

[Yuri Khan]

On Tue, Sep 25, 2018 at 12:41 AM Charles A. Roelli <charles@aurox.ch> wrote:

> Yes.  See the doc of "t-m-m":
>
>             The mark is "deactivated" by changing the buffer,
> and after certain other operations that set the mark but whose
> main purpose is something else--for example, incremental search,
> M-<, and M->.

FWIW, mark is not deactivated for me by incremental search.

$ emacs -Q
M-x emacs-version
→ GNU Emacs 26.1 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.18.9)
of 2018-05-29

1. In the *scratch* buffer, move point to the start of the word “buffer”.
2. Select the word “buffer” by holding down Shift and pressing <right>
six times.
3. Press C-s for isearch-forward.
4. Search for “text”.
5. Press RET to end incremental search.

Observed: “buffer is for text” is highlighted as region.

Expected: region is deactivated.

6. Move point using an unshifted arrow key.

Observed, expected: region is deactivated.


The ability to extend a region using isearch is occasionally useful,
but it would probably be better if it only behaved that way if invoked
as C-S-s or C-S-r (as a general case of shifted navigation command).
(Text terminal users are out of luck with Shift+Ctrl+letter bindings,
though.)

Re: visual-region-mode?

[Charles A. Roelli]

> From: Yuri Khan <yurivkhan@gmail.com>
> Date: Tue, 25 Sep 2018 01:07:24 +0700
> 
> On Tue, Sep 25, 2018 at 12:41 AM Charles A. Roelli <charles@aurox.ch> wrote:
> 
> > Yes.  See the doc of "t-m-m":
> >
> >             The mark is "deactivated" by changing the buffer,
> > and after certain other operations that set the mark but whose
> > main purpose is something else--for example, incremental search,
> > M-<, and M->.
> 
> FWIW, mark is not deactivated for me by incremental search.
> 
> $ emacs -Q
> M-x emacs-version
> → GNU Emacs 26.1 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.18.9)
> of 2018-05-29
> 
> 1. In the *scratch* buffer, move point to the start of the word “buffer”.
> 2. Select the word “buffer” by holding down Shift and pressing <right>
> six times.
> 3. Press C-s for isearch-forward.
> 4. Search for “text”.
> 5. Press RET to end incremental search.
> 
> Observed: “buffer is for text” is highlighted as region.
> 
> Expected: region is deactivated.
> 
> 6. Move point using an unshifted arrow key.
> 
> Observed, expected: region is deactivated.
> 
> 
> The ability to extend a region using isearch is occasionally useful,
> but it would probably be better if it only behaved that way if invoked
> as C-S-s or C-S-r (as a general case of shifted navigation command).
> (Text terminal users are out of luck with Shift+Ctrl+letter bindings,
> though.)

Yes, the documentation is wrong here, and probably needs a review.

There's more: in your recipe, ISEARCH actually does not set the mark
where the search was started (since the region is already active) --
to give the impression that ISEARCH "extends the region".  So the
documentation here is doubly wrong.

The manual tries to explain why ISEARCH sometimes does not push a
mark:

    When you exit the incremental search, it adds the original value of
  point to the mark ring, without activating the mark; you can thus use
  ‘C-u C-<SPC>’ or ‘C-x C-x’ to return to where you were before beginning
  the search.  *Note Mark Ring::.  (Emacs only does this if the mark was
  not already active; if the mark was active when you started the search,
  both 'C-u C-<SPC>' and 'C-x C-x' will go to the mark.)

The wording leaves something to be desired.  The parenthetical could
maybe say:

  Emacs only pushes the mark if it was not already active; if the mark
  was active when you started the search, both 'C-u C-<SPC>' and 'C-x
  C-x' will place point at the other end of the active region, not at
  the original value of point.

Also, isearch.el seems not to have any documentation about any of the
mark- or "t-m-m"-related behavior, at all.

Re: visual-region-mode?

[hw]

charles@aurox.ch (Charles A. Roelli) writes:


> [...]
> The manual tries to explain why ISEARCH sometimes does not push a
> mark:
>
>     When you exit the incremental search, it adds the original value of
>   point to the mark ring, without activating the mark; you can thus use
>   ‘C-u C-<SPC>’ or ‘C-x C-x’ to return to where you were before beginning
>   the search.  *Note Mark Ring::.  (Emacs only does this if the mark was
>   not already active; if the mark was active when you started the search,
>   both 'C-u C-<SPC>' and 'C-x C-x' will go to the mark.)
>
> The wording leaves something to be desired.  The parenthetical could
> maybe say:
>
>   Emacs only pushes the mark if it was not already active; if the mark
>   was active when you started the search, both 'C-u C-<SPC>' and 'C-x
>   C-x' will place point at the other end of the active region, not at
>   the original value of point.

This seems very confusing.  Is the region activated or the mark, or
both?

Isn't the region defined to be the part of the buffer between mark and
point?  If so, then point is always at one end of the region, active or
not, and there is no way to place it somewhere else.  IIUC, you can not
place point at the other end of the region when there is no mark to
exchange it with, and what happens to the mark when you do this when
searching incrementally?

Re: visual-region-mode?

[Charles A. Roelli]

> From: hw <hw@adminart.net>
> Cc: Yuri Khan <yurivkhan@gmail.com>,  emacs-devel@gnu.org
> Date: Wed, 03 Oct 2018 15:13:25 +0200
>
> > The wording leaves something to be desired.  The parenthetical could
> > maybe say:
> >
> >   Emacs only pushes the mark if it was not already active; if the mark
> >   was active when you started the search, both 'C-u C-<SPC>' and 'C-x
> >   C-x' will place point at the other end of the active region, not at
> >   the original value of point.
> 
> This seems very confusing.  Is the region activated or the mark, or
> both?

I've used the two terms interchangeably because they are equivalent.

> Isn't the region defined to be the part of the buffer between mark and
> point?  If so, then point is always at one end of the region, active or
> not, and there is no way to place it somewhere else.  IIUC, you can not
> place point at the other end of the region when there is no mark to
> exchange it with, and what happens to the mark when you do this when
> searching incrementally?

Yes, you can place point at the other end of an active region (that
is, at mark).  Naturally the active region will change, if that's all
you do.

Neither C-u C-SPC nor C-x C-x change their behavior when searching
incrementally; but ISEARCH changes its behavior based on whether the
region is active, and that is what needs better documentation.  This
kind of oversight makes "t-m-m" unwieldy, harder to customize and
unlikely to be a target for patches or improvement.  "t-m-m" reaches
into many places in Emacs where you might not have expected, and
turning it off is a convenient fix that guarantees (almost) no bother
from the mode.

Re: visual-region-mode?

[hw]

charles@aurox.ch (Charles A. Roelli) writes:

>> From: hw <hw@adminart.net>
>> Date: Fri, 21 Sep 2018 22:28:53 +0200
>>
>> > There would be a way to "fortify" the region, if you had another
>> > binding for toggling whether the region is active or not.
>> 
>> Without t-m-m, the region can not become active.
>
> Yes, but since we have commands that offer behavior specific to active
> regions, we have the so-called "temporary transient mark mode" --
> which is a hack to get around this problem.  I'd rather have a way to
> explicitly activate/deactivate the region.

I'm not sure this is a distinct mode; it seems more like the region is
activated regardless of t-m-m being enabled or not and gets somehow
disabled eventually.

It seems activate-mark enables the region.

>> >> With t-m-m disabled, the region can not be activated, so why would I try
>> >> to do that?  My function is ignorant of t-m-m anyway.
>> >> 
>> >> Why would I disable t-m-m only to ask to temporarily enable it?
>> >
>> > That's how the current implementation is designed: the region is
>> > considered "active" when both "mark-active" is non-nil /and/ "t-m-m"
>> > is on.
>> 
>> That doesn't explain why I would disable t-m-m.
>
> No, it explains why you would temporarily enable it after disabling it
> permanently.

Why would I disable it permanently?  I wouldn't have highlighting, there
would be no way to fortify the region --- which is a requirement because
it can not really be disabled due to a fundamental design flaw --- and I
would have to narrow the buffer all the time to do something with a
region and to widen it afterwards.

That would just be ridiculously awkward and inconvenient.

>> Perhaps there is a way to disable the highlighting.  I haven't found out
>> how something is highlighted.
>
> It's possible to disable the highlighting by customizing the "region"
> face.

Well, that's not really a way to disable it, but it could be used as a
workaround.  So nothing speaks against having t-m-m enabled, and lots of
things speak for it.

>> > and without the region randomly deactivating itself after certain
>> > commands as it does with "t-m-m" switched on.
>> 
>> [...]
>>
>> Are you referring to commands deactivating the region?  
>
> Yes.  See the doc of "t-m-m":
>
>             The mark is "deactivated" by changing the buffer,
> and after certain other operations that set the mark but whose
> main purpose is something else--for example, incremental search,
> M-<, and M->.

So this doesn't happen randomly but intentionally --- and you could
re-activate the region if you still want to do something with it.


>> 							  That could be
>> configurable, though I'm not sure how useful it is to indefinitely do
>> something with a region until it is explicitly deactivated.  
>
> That's how the region works with "t-m-m" off: you can always invoke a
> sequence of commands that use the region, without having to think
> about whether it's active.

Yes, and that's a design flaw because it means that the software makes
mistakes of users worse rather than protecting them from them.  Why
would anyone do stuff with random contents of a buffer, be it by
accident or otherwise?

> I'd like to be able to carry this behavior over to commands that
> require an active region for certain things, like M-% does for
> replacing inside a region.

I guess the right, or consistent, way to do that might be to write more
antagonistic functions that imply "region", like `query-replace-region'.

Why don't you make a selection when you want to do something with one?
With t-m-m enabled, that automatically activates the region, and it is
much better than doing stuff with random parts of the buffer.

Other than that, I wonder what would go wrong if you made a key binding
to a function that toggles `use-region-p' which you use before and
perhaps after calling functions you want to have a different behaviour.
Maybe `query-replace-region' could make use of that.

>> > Highlighting the region could be a separate mode.
>> 
>> Highlighting the region all the time is probably not very useful.
>
> Yes, but the user knows best, IMO.  The default would still be the
> same behavior as it is now.

Maybe, maybe not ...

>> >> Are there any disadvantages of having t-m-m enabled that would overcome
>> >> all the advantages of having it disabled?
>> >
>> > Not sure I understand this.
>> 
>> Disabling t-m-m doesn't make any sense at all.  Why would anyone disable
>> it?
>> 
>> I can see it for someone who doesn't like the highlighting, so if it was
>> configurable --- and it is amazing that is isn't --- whether to
>> highlight the region when it's active or not, everyone who dislikes the
>> highlighting could have t-m-m enabled.  I would remove having it
>> disabled entirely from Emacs because there is no point in that and only
>> complication.
>
> I think the main point of contention is C-x C-x: it activates the mark
> by default, which is irritating when you're using the mark for
> navigation.

Yeah that is messed up.

> Even if you disable the highlighting of the region, certain commands
> will behave differently in response to the region being active.

That doesn't really make sense.  Having t-m-m enabled is the default,
and there is no point and no sense in disabling it.  So don't disable
it, and your problems do not exist.

Of course, functions implying "region" don't make sense when t-m-m is
enabled: t-m-m already implies "region" in the sense of "selection",
somewhat overcoming the fundamental design flaw of "the region" and the
idea of doing stuff randomly with parts of buffers.  The functions
implying "region" are merely children of this design flaw because they
were only invented because nobody wants to narrow and widen their
buffers to do something with parts of them.

> You've already posted an improved version of C-x C-x that does not

I wouldn't call it "improved", only "different": it depends on what one
wants to happen.

> activate the mark by default: I think that is the right way to go, as
> well as a new command for explicitly activating/deactivating the mark.
> With these two fixes, much of the contention surrounding "t-m-m"
> should go.

Well, my fine keyboard broke, so I got out the Unicomp with 122 keys and
made more key bindings:


(global-set-key "\C-x\C-x" 'my-exchange-point-and-mark)
(global-set-key (kbd "<C-f1>")
		(lambda ()
		  "Toggle the activeness of the region."
		  (interactive)
		  (if mark-active (deactivate-mark)
		    (activate-mark t))))
(global-set-key [C-f2] 'my-exchange-point-and-mark)
(global-set-key [C-f3] 'previous-buffer)
(global-set-key [C-f5] 'next-buffer)


Those are actual keys, i. e. I press only one key for them.  It's rather
convenient.  (The key caps are labeled Print, Help, Record and Play.)

Unfortunately, it seems Unicomp is the only manufacturer still making
really good keyboards, and the only one for 122 keys ...  (The fine
keyboard started working again the next day after I banged it a little,
but I really like having more keys.)


On a side note, why is the function that activates the region called
activate-mark and not activate-region?  Is there some purpose or
distinction involved we don't know about?

> [...]
> Btw, I'm culling most of the CC list since it seems no longer relevant.

I don't know who/what created this list; I suspect it might have been
gnus.

Re: visual-region-mode?

[Charles A. Roelli]

> From: hw <hw@adminart.net>
> Cc: emacs-devel@gnu.org
> Date: Thu, 27 Sep 2018 00:00:42 +0200
>
> > Yes, but since we have commands that offer behavior specific to active
> > regions, we have the so-called "temporary transient mark mode" --
> > which is a hack to get around this problem.  I'd rather have a way to
> > explicitly activate/deactivate the region.
> 
> I'm not sure this is a distinct mode; it seems more like the region is
> activated regardless of t-m-m being enabled or not and gets somehow
> disabled eventually.

For what it's worth, the doc of the variable "transient-mark-mode" says:

- The pair (only . OLDVAL) enables Transient Mark mode
  temporarily.  After any subsequent point motion command that is
  not shift-translated, or any other action that would normally
  deactivate the mark (e.g. buffer modification), the value of
  ‘transient-mark-mode’ is set to OLDVAL.

> Why would I disable it permanently?  I wouldn't have highlighting, there
> would be no way to fortify the region --- which is a requirement because
> it can not really be disabled due to a fundamental design flaw --- and I
> would have to narrow the buffer all the time to do something with a
> region and to widen it afterwards.

You disable "t-m-m" if you don't want a "transient" mark -- as in,
activating and deactivating itself seemingly of its own volition.

> >> > and without the region randomly deactivating itself after certain
> >> > commands as it does with "t-m-m" switched on.
> >> 
> >> [...]
> >>
> >> Are you referring to commands deactivating the region?  
> >
> > Yes.  See the doc of "t-m-m":
> >
> >             The mark is "deactivated" by changing the buffer,
> > and after certain other operations that set the mark but whose
> > main purpose is something else--for example, incremental search,
> > M-<, and M->.
> 
> So this doesn't happen randomly but intentionally --- and you could
> re-activate the region if you still want to do something with it.

Actually, the documentation lacks at least one other case: scrolling
that results in point moving, either with the keyboard or with the
mouse.  That's one of several arbitrary decisions in the design of
t-m-m.

> > I'd like to be able to carry this behavior over to commands that
> > require an active region for certain things, like M-% does for
> > replacing inside a region.
> 
> I guess the right, or consistent, way to do that might be to write more
> antagonistic functions that imply "region", like `query-replace-region'.
> 
> Why don't you make a selection when you want to do something with one?
> With t-m-m enabled, that automatically activates the region, and it is
> much better than doing stuff with random parts of the buffer.

I'd rather tells Emacs when the region is active, than the other way
round.

> Other than that, I wonder what would go wrong if you made a key binding
> to a function that toggles `use-region-p' which you use before and
> perhaps after calling functions you want to have a different behaviour.
> Maybe `query-replace-region' could make use of that.

This would be a binding to activate or deactivate the region, I think.
No extra command ("query-replace-region") should be necessary.

> Of course, functions implying "region" don't make sense when t-m-m is
> enabled: t-m-m already implies "region" in the sense of "selection",
> somewhat overcoming the fundamental design flaw of "the region" and the
> idea of doing stuff randomly with parts of buffers.  The functions
> implying "region" are merely children of this design flaw because they
> were only invented because nobody wants to narrow and widen their
> buffers to do something with parts of them.

Narrowing still has its place in everyday editing.

> (global-set-key "\C-x\C-x" 'my-exchange-point-and-mark)
> (global-set-key (kbd "<C-f1>")
> 		(lambda ()
> 		  "Toggle the activeness of the region."
> 		  (interactive)
> 		  (if mark-active (deactivate-mark)
> 		    (activate-mark t))))
> (global-set-key [C-f2] 'my-exchange-point-and-mark)
> (global-set-key [C-f3] 'previous-buffer)
> (global-set-key [C-f5] 'next-buffer)
> 
> Those are actual keys, i. e. I press only one key for them.  It's rather
> convenient.  (The key caps are labeled Print, Help, Record and Play.)
> 
> Unfortunately, it seems Unicomp is the only manufacturer still making
> really good keyboards, and the only one for 122 keys ...  (The fine
> keyboard started working again the next day after I banged it a little,
> but I really like having more keys.)

Neat, let us know how this approach goes.  I don't know what key we
could allocate to a command that activates or deactivates the region,
since there are not free ones left on average keyboards...

> On a side note, why is the function that activates the region called
> activate-mark and not activate-region?  Is there some purpose or
> distinction involved we don't know about?

People use "active mark" and "active region" interchangeably, AFAIK.
(I know I do!)

> > [...]
> > Btw, I'm culling most of the CC list since it seems no longer relevant.
> 
> I don't know who/what created this list; I suspect it might have been
> gnus.

Those people had responded to this thread earlier, so they ended up on
the list automatically.

Re: visual-region-mode?

[hw]

charles@aurox.ch (Charles A. Roelli) writes:

>> From: hw <hw@adminart.net>
>> Cc: emacs-devel@gnu.org
>> Date: Thu, 27 Sep 2018 00:00:42 +0200
>>
>> > Yes, but since we have commands that offer behavior specific to active
>> > regions, we have the so-called "temporary transient mark mode" --
>> > which is a hack to get around this problem.  I'd rather have a way to
>> > explicitly activate/deactivate the region.
>> 
>> I'm not sure this is a distinct mode; it seems more like the region is
>> activated regardless of t-m-m being enabled or not and gets somehow
>> disabled eventually.
>
> For what it's worth, the doc of the variable "transient-mark-mode" says:
>
> - The pair (only . OLDVAL) enables Transient Mark mode
>   temporarily.  After any subsequent point motion command that is
>   not shift-translated, or any other action that would normally
>   deactivate the mark (e.g. buffer modification), the value of
>   ‘transient-mark-mode’ is set to OLDVAL.

That sheds some light on the definition of exchange-point-and-mark in
simple.el which I didn't fully understand.  It either activates the
region or deactivates it, i. e. there doesn't seem to be anything
temporary about it.

"Temporary" only seems to mean that the mode is enabled until the region
is deactivated.  That doesn't mean that it is actually temporary; it's
the very same mode --- or isn't it?

>> Why would I disable it permanently?  I wouldn't have highlighting, there
>> would be no way to fortify the region --- which is a requirement because
>> it can not really be disabled due to a fundamental design flaw --- and I
>> would have to narrow the buffer all the time to do something with a
>> region and to widen it afterwards.
>
> You disable "t-m-m" if you don't want a "transient" mark -- as in,
> activating and deactivating itself seemingly of its own volition.

That isn't what it does.  There are only very few cases where I expect
the region to be deactivated and it isn't deactivated, and no cases in
which the region is somehow activated all on its own.

So why would I disable t-m-m?

>> >> > and without the region randomly deactivating itself after certain
>> >> > commands as it does with "t-m-m" switched on.
>> >> 
>> >> [...]
>> >>
>> >> Are you referring to commands deactivating the region?  
>> >
>> > Yes.  See the doc of "t-m-m":
>> >
>> >             The mark is "deactivated" by changing the buffer,
>> > and after certain other operations that set the mark but whose
>> > main purpose is something else--for example, incremental search,
>> > M-<, and M->.
>> 
>> So this doesn't happen randomly but intentionally --- and you could
>> re-activate the region if you still want to do something with it.
>
> Actually, the documentation lacks at least one other case: scrolling
> that results in point moving, either with the keyboard or with the
> mouse.  That's one of several arbitrary decisions in the design of
> t-m-m.

That shows the fundamental design flaw of Emacs which doesn't allow to
separate the region and thus selections from where the cursor is.  I
don't see how you could blame t-m-m for it.

>> > I'd like to be able to carry this behavior over to commands that
>> > require an active region for certain things, like M-% does for
>> > replacing inside a region.
>> 
>> I guess the right, or consistent, way to do that might be to write more
>> antagonistic functions that imply "region", like `query-replace-region'.
>> 
>> Why don't you make a selection when you want to do something with one?
>> With t-m-m enabled, that automatically activates the region, and it is
>> much better than doing stuff with random parts of the buffer.
>
> I'd rather tells Emacs when the region is active, than the other way
> round.

So you would rather have a "persistent region", i. e. a selection like
joe has?  Unfortunately, we can't really have that (unless the zones
Drew suggested work in this way), and t-m-m is what comes closest to it.

>> Other than that, I wonder what would go wrong if you made a key binding
>> to a function that toggles `use-region-p' which you use before and
>> perhaps after calling functions you want to have a different behaviour.
>> Maybe `query-replace-region' could make use of that.
>
> This would be a binding to activate or deactivate the region, I think.
> No extra command ("query-replace-region") should be necessary.

It depends on what you prefer: extra commands to do stuff limited to the
region, consistent with such commands that already exist, or explicitly
activate the region to limit any command to do stuff with it.

The latter could be what the temporaryness for t-m-m is supposed to
cover.  I simply leave t-m-m always enabled and have a key binding to
activate the region with when I want to.  The region is also fortified,
and it does what I want.

>> Of course, functions implying "region" don't make sense when t-m-m is
>> enabled: t-m-m already implies "region" in the sense of "selection",
>> somewhat overcoming the fundamental design flaw of "the region" and the
>> idea of doing stuff randomly with parts of buffers.  The functions
>> implying "region" are merely children of this design flaw because they
>> were only invented because nobody wants to narrow and widen their
>> buffers to do something with parts of them.
>
> Narrowing still has its place in everyday editing.

What do you use it for?

>> (global-set-key "\C-x\C-x" 'my-exchange-point-and-mark)
>> (global-set-key (kbd "<C-f1>")
>> 		(lambda ()
>> 		  "Toggle the activeness of the region."
>> 		  (interactive)
>> 		  (if mark-active (deactivate-mark)
>> 		    (activate-mark t))))
>> (global-set-key [C-f2] 'my-exchange-point-and-mark)
>> (global-set-key [C-f3] 'previous-buffer)
>> (global-set-key [C-f5] 'next-buffer)
>> 
>> Those are actual keys, i. e. I press only one key for them.  It's rather
>> convenient.  (The key caps are labeled Print, Help, Record and Play.)
>> 
>> Unfortunately, it seems Unicomp is the only manufacturer still making
>> really good keyboards, and the only one for 122 keys ...  (The fine
>> keyboard started working again the next day after I banged it a little,
>> but I really like having more keys.)
>
> Neat, let us know how this approach goes.

So far, it's nice.  I need to do some programming to really find out,
and it will be a while before I get to that.

> I don't know what key we could allocate to a command that activates or
> deactivates the region, since there are not free ones left on average
> keyboards...

That's why I like to have more keys.  You could get one of these
keyboards, they're awesome.  The keyboard is part of customization.

Other than that, having C-x C-x changed already helps, and in lack of
another key, you could use it with the prefix to toggle the activeness
of the region.

>> On a side note, why is the function that activates the region called
>> activate-mark and not activate-region?  Is there some purpose or
>> distinction involved we don't know about?
>
> People use "active mark" and "active region" interchangeably, AFAIK.
> (I know I do!)

That's confusing, and you could even have it so that activating the mark
creates a persistent selection that isn't disabled after doing something
with it while activating the region activates the selection only until
you did something with it.

>> > [...]
>> > Btw, I'm culling most of the CC list since it seems no longer relevant.
>> 
>> I don't know who/what created this list; I suspect it might have been
>> gnus.
>
> Those people had responded to this thread earlier, so they ended up on
> the list automatically.

Hm, that's an interesting feature.

Re: visual-region-mode?

[Alan Mackenzie]

Hello, hw.

On Fri, Sep 21, 2018 at 22:28:53 +0200, hw wrote:
> charles@aurox.ch (Charles A. Roelli) writes:

> >> From: hw <hw@adminart.net>
> >> Date: Wed, 19 Sep 2018 22:04:14 +0200

> >> With t-m-m disabled, there is no way to fortify the region, and there is
> >> no highlighting.  Why would I disable it?

[ .... ]

> Disabling t-m-m doesn't make any sense at all.  Why would anyone disable
> it?

For the avoidance of the complexities that dealing with
transient-mark-mode involves.

> I can see it for someone who doesn't like the highlighting, so if it was
> configurable --- and it is amazing that is isn't --- whether to
> highlight the region when it's active or not, everyone who dislikes the
> highlighting could have t-m-m enabled.  I would remove having it
> disabled entirely from Emacs because there is no point in that and only
> complication.

There is a great deal of point.  Your last suggestion borders on the
offensive, since it suggests that any user whose needs and understanding
are different from yours should not be taken into account in plotting the
future of Emacs.

I do agree with you that transient-mark-mode is a hodge-podge of vaguely
related distinct features, mostly badly named, and that was why I argued
against it becoming a default setting some years ago.

I also agree with you that these distinct features should be capable of
being en/disabled independently.  These distinct features are (i) the
highlighting of the region; (ii) the disablement of commands which need
the mark to function; (iii) the "narrowing" of the buffer for certain
commands (such as M-%).

> Without highlighting, a different indicator could be useful to show
> whether the region is active or not, like a hint in the mode line.

Yes.  I suggest this should be a single character, or at most two
characters.  Space in the mode line is precious.  Maybe "+" could fulfil
this role somewhere.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: visual-region-mode?

[Charles A. Roelli]

> Date: Mon, 24 Sep 2018 20:24:01 +0000
> From: Alan Mackenzie <acm@muc.de>
>
> > Without highlighting, a different indicator could be useful to show
> > whether the region is active or not, like a hint in the mode line.
> 
> Yes.  I suggest this should be a single character, or at most two
> characters.  Space in the mode line is precious.  Maybe "+" could fulfil
> this role somewhere.

Do you think it could also be useful to allow activating the region
when t-m-m is off?  Here is how that could be different to the current
"temporary transient mark mode" activated with C-u C-x C-x:

- the command to activate or deactivate the region would have a binding
- the region would, by default, never be activated or deactivated by
  anybody but the user

How to highlight the region (and when to do it) would be separately
customizable.

Re: visual-region-mode?

[hw]

Alan Mackenzie <acm@muc.de> writes:

> Hello, hw.
>
> On Fri, Sep 21, 2018 at 22:28:53 +0200, hw wrote:
>> charles@aurox.ch (Charles A. Roelli) writes:
>
>> >> From: hw <hw@adminart.net>
>> >> Date: Wed, 19 Sep 2018 22:04:14 +0200
>
>> >> With t-m-m disabled, there is no way to fortify the region, and there is
>> >> no highlighting.  Why would I disable it?
>
> [ .... ]
>
>> Disabling t-m-m doesn't make any sense at all.  Why would anyone disable
>> it?
>
> For the avoidance of the complexities that dealing with
> transient-mark-mode involves.

Which complexities do you mean?

>> I can see it for someone who doesn't like the highlighting, so if it was
>> configurable --- and it is amazing that is isn't --- whether to
>> highlight the region when it's active or not, everyone who dislikes the
>> highlighting could have t-m-m enabled.  I would remove having it
>> disabled entirely from Emacs because there is no point in that and only
>> complication.
>
> There is a great deal of point.

Which is?

> Your last suggestion borders on the offensive, since it suggests that
> any user whose needs and understanding are different from yours should
> not be taken into account in plotting the future of Emacs.

It doesn't suggest that; it only suggests to remove functionality that
is pointless and unnecessary and, along with it, a great deal of
complexity and inconsistency which accompany it.

Do you have an example of something that could not be accomplished with
transient-mark-mode enabled and only with it disabled?

> I do agree with you that transient-mark-mode is a hodge-podge of vaguely
> related distinct features, mostly badly named, and that was why I argued
> against it becoming a default setting some years ago.

I didn't say that t-m-m is a hodge-podge.

> I also agree with you that these distinct features should be capable of
> being en/disabled independently.  These distinct features are (i) the
> highlighting of the region; (ii) the disablement of commands which need
> the mark to function;

Do you mean it should be possible to disable commands that want the
region to be active to do something?  That would at least need
clarification of the intention, i. e. was the intention to limit them to
the region, to extend them to the region, or both? --- Commands are
already disabled when t-m-m is enabled and mark-even-if-inactive is nil,
so why do there need to be more ways to disable them?  Not that I, in
theory, wouldn't appreciate a way to fortify the region when t-m-m is
disabled, but since there is no point in disabling it, I don't see a
need for one (But you could disable the mark, see below.)

Instead of voting for more ways to disable commands, I might argue to
remove the functions that imply "region" because implying to do stuff
with a region is unnecessary when t-m-m is enabled because t-m-m means
to do anything either with a region or not, depending on whether the
region is active or not.

What's the point and the advantage of duplicating all commands that can
do stuff with the contents of a buffer only because a fundamental design
flaw makes it so inefficient to determine whether commands should do
their things with the whole buffer or with a part of it by requiring the
user to narrow and to widen the buffer in order to make that
determination?

I don't understand why this wasn't simply overcome by setting the mark
to nil.  You could have *one* set of commands instead of several, and if
you wanted them to do their things with the region, do not have the mark
set to nil, and if you want them to work on the whole buffer, just set
the mark to nil.  You wouldn't need t-m-m then, would you (except for
the highlighting)?

> (iii) the "narrowing" of the buffer for certain
> commands (such as M-%).

Is narrowing the buffer sometimes disabled?  How do you determine to
which parts you want to narrow buffers to without selecting either the
relevant parts or the irrelevant parts?

>> Without highlighting, a different indicator could be useful to show
>> whether the region is active or not, like a hint in the mode line.
>
> Yes.  I suggest this should be a single character, or at most two
> characters.  Space in the mode line is precious.  Maybe "+" could fulfil
> this role somewhere.

Right, though '+' would make me think that there is more to display
while there isn't, like because there isn't enough room for it.
Changing the colour of the mode line might work, too.

Re: visual-region-mode?

[Alan Mackenzie]

Hello, hw.

On Thu, Sep 27, 2018 at 00:45:59 +0200, hw wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > Hello, hw.

> > On Fri, Sep 21, 2018 at 22:28:53 +0200, hw wrote:
> >> charles@aurox.ch (Charles A. Roelli) writes:

> >> >> From: hw <hw@adminart.net>
> >> >> Date: Wed, 19 Sep 2018 22:04:14 +0200

> >> >> With t-m-m disabled, there is no way to fortify the region, and there is
> >> >> no highlighting.  Why would I disable it?

> > [ .... ]

> >> Disabling t-m-m doesn't make any sense at all.  Why would anyone disable
> >> it?

> > For the avoidance of the complexities that dealing with
> > transient-mark-mode involves.

> Which complexities do you mean?

The ones I've outlined in previous posts to you.  You've shown no sign in
the past of having understood what I've said.  So I'll say it one last
time.  This time please pay attention.

The complexity I'm referring to is having "modes" (like vi's insert and
command mode) in Emacs where a single command does different things
according to the mode.  This happens with transient-mark-mode enabled,
the two modes being mark "active" and mark not "active".  This complexity
is avoided by disabling transient-mark-mode.

[ .... ]

> > Your last suggestion borders on the offensive, since it suggests that
> > any user whose needs and understanding are different from yours
> > should not be taken into account in plotting the future of Emacs.

> It doesn't suggest that; it only suggests to remove functionality that
> is pointless and unnecessary and, along with it, a great deal of
> complexity and inconsistency which accompany it.

You _are_ becoming offensive.  Your personal preferences are NOT
objective goodness.  You have your way of using Emacs, and you should not
try to force it onto me.  Thankfully, the maintainers of Emacs are not
about to remove the choice.

> Do you have an example of something that could not be accomplished with
> transient-mark-mode enabled and only with it disabled?

No, of course not.  Any editing result can be achieved with t-m-m either
enabled or disabled.  If you really were interested in simplicity, you
would be advocating abolishing transient-mark-mode completely.  Emacs is
simpler without it, and still a full-featured editor (as it was in the
decades before transient-mark-mode was written).  It would make lots of
users unhappy, though.

> > I do agree with you that transient-mark-mode is a hodge-podge of vaguely
> > related distinct features, mostly badly named, and that was why I argued
> > against it becoming a default setting some years ago.

> I didn't say that t-m-m is a hodge-podge.

Sorry, those were my words, not yours.

> > I also agree with you that these distinct features should be capable of
> > being en/disabled independently.  These distinct features are (i) the
> > highlighting of the region; (ii) the disablement of commands which need
> > the mark to function;

> Do you mean it should be possible to disable commands that want the
> region to be active to do something?

No, I meant precisely what I wrote.  I did not mention the region.

> That would at least need clarification of the intention, i. e. was the
> intention to limit them to the region, to extend them to the region, or
> both?

With transient-mark-mode disabled, you avoid this complexity.  ;-)

> --- Commands are already disabled when t-m-m is enabled and
> mark-even-if-inactive is nil, so why do there need to be more ways to
> disable them?

Please read again what I wrote, and concentrate.

> Not that I, in theory, wouldn't appreciate a way to fortify the region
> ....

To WHAT the region?  "Fortify" is not Emacs terminology.

> .... when t-m-m is disabled, but since there is no point in disabling
> it, ...

You are simply wrong on this point.  I wish you would stop incessantly
repeating it.

> .... I don't see a need for one (But you could disable the mark, see
> below.)

> Instead of voting for more ways to disable commands, ....

Nobody is advocating this.

> .... I might argue to remove the functions that imply "region" because
> implying to do stuff with a region is unnecessary when t-m-m is enabled
> because t-m-m means to do anything either with a region or not,
> depending on whether the region is active or not.

You would be better not so to argue.

> What's the point and the advantage of duplicating all commands that can
> do stuff with the contents of a buffer only because a fundamental design
> flaw makes it so inefficient to determine whether commands should do
> their things with the whole buffer or with a part of it by requiring the
> user to narrow and to widen the buffer in order to make that
> determination?

Would you please stop insinuating that a feature of Emacs which you
happen not to like is a "fundamental design flaw".  It is insulting to
generations of Emacs developers, and is not true.  Your thinking it is
based on your lack of a deeper understanding of Emacs' design, purpose
and history.

> I don't understand why this wasn't simply overcome by setting the mark
> to nil.  You could have *one* set of commands instead of several, and if
> you wanted them to do their things with the region, do not have the mark
> set to nil, and if you want them to work on the whole buffer, just set
> the mark to nil.  You wouldn't need t-m-m then, would you (except for
> the highlighting)?

Setting the mark to nil at any time would reduce its effectiveness for
navigation.

> > (iii) the "narrowing" of the buffer for certain
> > commands (such as M-%).

> Is narrowing the buffer sometimes disabled?

No.

> How do you determine to which parts you want to narrow buffers to
> without selecting either the relevant parts or the irrelevant parts?

C-x n n   narrow-to-region (after setting mark and moving point); or
C-x n d   narrow-to-defun; or
C-x n p   narrow-to-page.
And when you're finishied,
C-x n w   widen.

> >> Without highlighting, a different indicator could be useful to show
> >> whether the region is active or not, like a hint in the mode line.

> > Yes.  I suggest this should be a single character, or at most two
> > characters.  Space in the mode line is precious.  Maybe "+" could fulfil
> > this role somewhere.

> Right, though '+' would make me think that there is more to display
> while there isn't, like because there isn't enough room for it.
> Changing the colour of the mode line might work, too.

I suppose so.  Though I'd be more in favour of changing the colour of
just a small part of the mode line, to minimise the reduction in
readability.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: visual-region-mode?

[hw]

Alan Mackenzie <acm@muc.de> writes:

> Hello, hw.
>
> On Thu, Sep 27, 2018 at 00:45:59 +0200, hw wrote:
>> Alan Mackenzie <acm@muc.de> writes:
>
>> > Hello, hw.
>
>> > On Fri, Sep 21, 2018 at 22:28:53 +0200, hw wrote:
>> >> charles@aurox.ch (Charles A. Roelli) writes:
>
>> >> >> From: hw <hw@adminart.net>
>> >> >> Date: Wed, 19 Sep 2018 22:04:14 +0200
>
>> >> >> With t-m-m disabled, there is no way to fortify the region, and there is
>> >> >> no highlighting.  Why would I disable it?
>
>> > [ .... ]
>
>> >> Disabling t-m-m doesn't make any sense at all.  Why would anyone disable
>> >> it?
>
>> > For the avoidance of the complexities that dealing with
>> > transient-mark-mode involves.
>
>> Which complexities do you mean?
>
> The ones I've outlined in previous posts to you.  You've shown no sign in
> the past of having understood what I've said.  So I'll say it one last
> time.  This time please pay attention.
>
> The complexity I'm referring to is having "modes" (like vi's insert and
> command mode) in Emacs where a single command does different things
> according to the mode.  This happens with transient-mark-mode enabled,
> the two modes being mark "active" and mark not "active".  This complexity
> is avoided by disabling transient-mark-mode.

I must be blind?  Where did you say this before?

I'm saying all this complexity is avoided by removing the possibility of
having transient-mark-mode disabled, and that there is no need for two
different sets of commands when t-m-m is enabled.

There is also only advantages of having t-m-m enabled and only
disadvantages having it disabled, so why disable it?  If you never
disable it, you don't need to deal with the complexity, though it
remains in the sources until removed.

> [ .... ]
>
>> > Your last suggestion borders on the offensive, since it suggests that
>> > any user whose needs and understanding are different from yours
>> > should not be taken into account in plotting the future of Emacs.
>
>> It doesn't suggest that; it only suggests to remove functionality that
>> is pointless and unnecessary and, along with it, a great deal of
>> complexity and inconsistency which accompany it.
>
> You _are_ becoming offensive.  Your personal preferences are NOT
> objective goodness.  You have your way of using Emacs, and you should not
> try to force it onto me.  Thankfully, the maintainers of Emacs are not
> about to remove the choice.

I didn't say that my preferences are good for everyone and am not trying
to force them upon anyone.  I'm merely suggesting that something
unnecessary could be removed.

>> Do you have an example of something that could not be accomplished with
>> transient-mark-mode enabled and only with it disabled?
>
> No, of course not.  Any editing result can be achieved with t-m-m either
> enabled or disabled.  If you really were interested in simplicity, you
> would be advocating abolishing transient-mark-mode completely.  Emacs is
> simpler without it, and still a full-featured editor (as it was in the
> decades before transient-mark-mode was written).  It would make lots of
> users unhappy, though.

See above, you don't like the complexity, and you'd rather remove
transient-mark-mode than you'd remove the possibility of disabling it. I
don't find that offensive, though it seems to me that you have some hate
for t-m-m for unknown reasons, and I still don't understand why you
would disable and remove it and still don't see any advantages of having
it disabled.

Nobody has yet shown any advantages of having t-m-m disabled.

> [...]
>> > I also agree with you that these distinct features should be capable of
>> > being en/disabled independently.  These distinct features are (i) the
>> > highlighting of the region; (ii) the disablement of commands which need
>> > the mark to function;
>
>> Do you mean it should be possible to disable commands that want the
>> region to be active to do something?
>
> No, I meant precisely what I wrote.  I did not mention the region.

The mark implies region, and why would you want to disable commands that
need the mark to function?

>> That would at least need clarification of the intention, i. e. was the
>> intention to limit them to the region, to extend them to the region, or
>> both?
>
> With transient-mark-mode disabled, you avoid this complexity.  ;-)

Not really: you would need to narrow or to widen the buffer depending on
the intention, and that is way more complicated than making a selection
and doing something with it.

You could much better avoid this complexity by clarifying the intention
of having a selection --- reasonably to the understanding that, for
functions, it means to do their thing with the selection, regardless of
whether it means to limit or to extend their doing to it.  For this, it
doesn't matter what t-m-m originally meant.

There goes all the complexity out the window.

>> --- Commands are already disabled when t-m-m is enabled and
>> mark-even-if-inactive is nil, so why do there need to be more ways to
>> disable them?
>
> Please read again what I wrote, and concentrate.

see above

>> Not that I, in theory, wouldn't appreciate a way to fortify the region
>> ....
>
> To WHAT the region?  "Fortify" is not Emacs terminology.

Yet Emacs can already fortify the region.  If you want to stick with
Emacs terminology, how would you ever make any progress?

>> .... when t-m-m is disabled, but since there is no point in disabling
>> it, ...
>
> You are simply wrong on this point.  I wish you would stop incessantly
> repeating it.

What would be the point of disabling t-m-m?  I wish you could show one.

>> .... I don't see a need for one (But you could disable the mark, see
>> below.)
>
>> Instead of voting for more ways to disable commands, ....
>
> Nobody is advocating this.

You want an independent way to disable commands that need the mark to
function.  Isn't that voting for more ways to disable commands?

>> .... I might argue to remove the functions that imply "region" because
>> implying to do stuff with a region is unnecessary when t-m-m is enabled
>> because t-m-m means to do anything either with a region or not,
>> depending on whether the region is active or not.
>
> You would be better not so to argue.

Why not?  Does having two sets of functions that do the same thing, once
with the selection, once with random parts of the buffer unless you
kinda make a selection by narrowing it, reduce complexity?  Or does it
have some advantages?

>> What's the point and the advantage of duplicating all commands that can
>> do stuff with the contents of a buffer only because a fundamental design
>> flaw makes it so inefficient to determine whether commands should do
>> their things with the whole buffer or with a part of it by requiring the
>> user to narrow and to widen the buffer in order to make that
>> determination?
>
> Would you please stop insinuating that a feature of Emacs which you
> happen not to like is a "fundamental design flaw".  It is insulting to
> generations of Emacs developers, and is not true.  Your thinking it is
> based on your lack of a deeper understanding of Emacs' design, purpose
> and history.

Maybe you can explain to me how it is not a design flaw that navigating
and making and having a selection --- or having random parts of a buffer
always threatened by mistakes --- are inseparable from each other and
how this design flaw is not a fundamental one while Emacs is built upon
this.

Imagine a hundred years ago a bridge was built from wood which now can
not withstand the traffic it would need to carry because the wood simply
can't handle the load.  It was a design flaw to build it from wood
rather than steel, and it's a fundamental design flaw because changing
that would mean to build a new bridge.  Now I call it a fundamental
design flaw --- and you would expect the people who built and maintained
the bridge to be insulted?

They would probably laugh about it.  If they don't, they should.  It's
still a fundamental design flaw that can not be changed, so what.

Duplicating all commands for Emacs that can do something with contents
of a buffer still doesn't seem advantageous.

>> I don't understand why this wasn't simply overcome by setting the mark
>> to nil.  You could have *one* set of commands instead of several, and if
>> you wanted them to do their things with the region, do not have the mark
>> set to nil, and if you want them to work on the whole buffer, just set
>> the mark to nil.  You wouldn't need t-m-m then, would you (except for
>> the highlighting)?
>
> Setting the mark to nil at any time would reduce its effectiveness for
> navigation.

There you see the design flaw.

>> > (iii) the "narrowing" of the buffer for certain
>> > commands (such as M-%).
>
>> Is narrowing the buffer sometimes disabled?
>
> No.

Why do you need to independently disable it?

>> How do you determine to which parts you want to narrow buffers to
>> without selecting either the relevant parts or the irrelevant parts?
>
> C-x n n   narrow-to-region (after setting mark and moving point); or
> C-x n d   narrow-to-defun; or
> C-x n p   narrow-to-page.
> And when you're finishied,
> C-x n w   widen.

That's either:


+ make a selection and then narrow to it, or

+ determine whether you are within something that would count as a
  defun, then determine if all the brackets (or whatever is used) are
  balanced, then narrow to it, using yet another key binding, or

+ Who is using pages?, or

+ do something with the narrowed buffer, then widen it, using yet
  another key binding


This doesn't account for that the units you would narrow to would have
to happen the part of the buffer you want to do something with, which is
the most unlikely case.  You also need to remember four different key
bindings.  Though it's a valid example, I wouldn't say it's something
practical.

Instead of all this, you can just make a selection and do something with
it, all without any further ado, without having to remember lots of key
bindings and without needing to determine first if any of them is
currently applicable.  You can't do that when t-m-m is disabled, and
still you insist on having it disabled.  Can't you see how t-m-m reduces
complexity, which is what you wanted?  And where is the point in
disabling it?

>> >> Without highlighting, a different indicator could be useful to show
>> >> whether the region is active or not, like a hint in the mode line.
>
>> > Yes.  I suggest this should be a single character, or at most two
>> > characters.  Space in the mode line is precious.  Maybe "+" could fulfil
>> > this role somewhere.
>
>> Right, though '+' would make me think that there is more to display
>> while there isn't, like because there isn't enough room for it.
>> Changing the colour of the mode line might work, too.
>
> I suppose so.  Though I'd be more in favour of changing the colour of
> just a small part of the mode line, to minimise the reduction in
> readability.

That could be optional.

Re: visual-region-mode?

[Alan Mackenzie]

Hello, hw

On Wed, Oct 03, 2018 at 17:43:46 +0200, hw wrote:

[ .... ]

That time has come.  For many, many posts you have been deliberately
misunderstanding, misconstruing, and twisting plainly expressed views,
with the aim of provoking maximum irritation, insulting all of us here,
and generally wasting people's time and energy.

In short, you are a troll - an anonymous troll.  I have finished feeding
you, and if it were up to me, I would tell you you are no longer welcome
on this list.

Cheerio.

-- 
Alan Mackenzie (Nuremberg, Germany).

RE: visual-region-mode?

[Drew Adams]

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

> > Without highlighting, a different indicator could be useful to show
> > whether the region is active or not, like a hint in the mode line.
> 
> Yes, offering an indicator in the mode line to show whether the
> region is active would be a good start.

FWIW, my library `modeline-posn.el' provides such a mode-line
indication.

When the region is active, `size-indication-mode' does these things
(optionally):

* Shows the size of the region (or the shape/size if rectangular),
   instead of the buffer size.
* Shows that the current command acts on the active region or
   acts specially because the region is active.

You can customize the info for the first bullet. Choices for this include
(a) the number of chars, (b) the number of bytes, (c) the number of
chars and number of lines (or the number of rows and number of
columns, if a rectangle is selected), and (d) anything else you
might want.  Choice (c) is the default (shown in attached screenshot).

Option `modelinepos-empty-region-flag' determines whether to
show the active-region indication when the active region is empty.

Attached screenshot shows the mode-line indication. The red box
on the face indicates that the region is active, and it currently has
149 characters.

It shows Isearch restricted to the region (an Isearch+ feature).
The region changes while searching (because the cursor moves),
so the region size (number of chars) also indicates the cursor
position relative to the original start of the region.

The face used to highlight the `size-indication-mode' part of
the mode-line changes to reflect region activation. If the current
command did not treat the active region specially then the face
in the screenshot would not include the surrounding red box. It
would just show the region-face background (by default).
(Two faces are used for the size highlighting: one for normal
and one to show that the current command acts specially.)

Commands use variable `modelinepos-region-acting-on' to
control when to show that they act specially on the region.
For example, this is how I make `rectangle-mark-mode'
turn this indication on and off:

(defadvice rectangle-mark-mode (after
                                bind-modelinepos-region-acting-on
                                activate)
  (setq modelinepos-region-acting-on  rectangle-mark-mode
        modelinepos-rect-p            rectangle-mark-mode)  
  (redisplay 'force))

https://www.emacswiki.org/emacs/ModeLinePosition

[-- Attachment #2: drew-emacs-modeline-region-isearch.png --]
[-- Type: image/png, Size: 9819 bytes --]

Re: visual-region-mode?

[Juri Linkov]

> I don't think there can currently be multiple regions at the same time.

Multiple regions are already supported - rectangle region is
one implementation of non-contiguous regions.  So you can define
your own region shape by extending region-extract-function and
redisplay-highlight-region-function to e.g. put region boundaries
at positions of marks from mark-ring where C-SPC will add more parts
to the region.

> As for doing other things, like replacing text in multiple parts of a
> buffer, is that something that could be usefully done with indirect
> buffers?  With multiple regions, I'd highlight some parts of the buffer,
> do the replacement limited to these parts and would be done with it.
> I'd be able to see all of the buffer while doing this.

query-replace already supports multiple regions.

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)

[Phil Sainty]

*Personally* I dislike `delete-selection-mode'; but FWIW I also
don't have a big issue with disabling it in my init file -- at
the end of the day it's an easy change to make to get back to
the behaviour I prefer.

I can't imagine that many users who use the current default
behaviour would continue to use the default if the default were
*changed*; so either way a sub-set of users will always be forced
to set `delete-selection-mode' in their init files -- which means
it's a question of whether we're more interested in minimising
friction for existing users who still prefer the current default,
or for new users who are probably used to the behaviour of other
text-editors.


I think what I'd be most in favour of would be a new link on the
splash screen which invited users to customize some of the most
fundamental aspects in which the default Emacs behaviours
conflict with the typical behaviour of newer applications with
which the user may be more familiar.  I think this would be one
of those options.  CUA mode would be another.

This set of options could be added to over time (as and when new
user options were added to provide compatibility with the way that
other editors and applications work), such that new Emacs users
can always have a smoother introduction offered to them, without
interfering with the upgrade experience of existing users.

Such a feature would be like an improved/interactive alternative
to the "Migrating to Emacs" section of the "Emacs Guided Tour"
web page.

Of course that entails someone spending their time implementing
a feature which doesn't benefit them in any way -- because *they*
already know how to set all the options in question.

User options can belong to multiple groups though, can't they?
Perhaps an initial implementation is as simple as identifying
such options, adding them to a common group, and linking to that
group from the splash screen?


On 2018-09-07 18:47, 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.

I am quite surprised by the notion that there are users who are
using `delete-selection-mode' in some modes and not others?!  My
instinct is that that would be extremely confusing, so I wouldn't
be in favour of any default behaviour where the mode was sometimes
on and sometimes off.  I think the default should be consistent
one way or the other.


-Phil

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

[Eli Zaretskii]

> Date: Fri, 07 Sep 2018 21:40:26 +1200
> From: Phil Sainty <psainty@orcon.net.nz>
> 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
> 
> I think what I'd be most in favour of would be a new link on the
> splash screen which invited users to customize some of the most
> fundamental aspects in which the default Emacs behaviours
> conflict with the typical behaviour of newer applications with
> which the user may be more familiar.  I think this would be one
> of those options.  CUA mode would be another.

Patches to that effect are welcome.

> User options can belong to multiple groups though, can't they?
> Perhaps an initial implementation is as simple as identifying
> such options, adding them to a common group, and linking to that
> group from the splash screen?

I suggested that in a recent thread, so I'm in favor of identifying
these groups.

Thanks.

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

[Phil Sainty]

On 08/09/18 01:41, Eli Zaretskii wrote:
>> User options can belong to multiple groups though, can't they?
>> Perhaps an initial implementation is as simple as identifying
>> such options, adding them to a common group, and linking to that
>> group from the splash screen?
> 
> I suggested that in a recent thread, so I'm in favor of identifying
> these groups.

Oh, very good.  I didn't remember it, but perhaps I read that.

Were there other particular user options which were mentioned when
you first raised this idea?  (Do you remember which thread that
was?)

I feel like this should become a bug report, for tracking purposes.


-Phil

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

[Eli Zaretskii]

> Cc: npostavs@gmail.com, hw@adminart.net, spacibba@aol.com,
>  phillip.lord@russet.org.uk, drew.adams@oracle.com, emacs-devel@gnu.org
> From: Phil Sainty <psainty@orcon.net.nz>
> Date: Sat, 8 Sep 2018 23:37:41 +1200
> 
> On 08/09/18 01:41, Eli Zaretskii wrote:
> >> User options can belong to multiple groups though, can't they?
> >> Perhaps an initial implementation is as simple as identifying
> >> such options, adding them to a common group, and linking to that
> >> group from the splash screen?
> > 
> > I suggested that in a recent thread, so I'm in favor of identifying
> > these groups.
> 
> Oh, very good.  I didn't remember it, but perhaps I read that.
> 
> Were there other particular user options which were mentioned when
> you first raised this idea?

The idea I described was to do it the other way around: first identify
the groups of users, and then come up with the list of options
pertinent for each group.

> (Do you remember which thread that was?)

My message was here:

  http://lists.gnu.org/archive/html/emacs-devel/2018-08/msg00794.html

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

[Drew Adams]

> *Personally* I dislike `delete-selection-mode'; but FWIW I also
> don't have a big issue with disabling it in my init file -- at
> the end of the day it's an easy change to make to get back to
> the behaviour I prefer.
> 
> I can't imagine that many users who use the current default
> behaviour would continue to use the default if the default were
> *changed*; so either way a sub-set of users will always be forced
> to set `delete-selection-mode' in their init files -- which means
> it's a question of whether we're more interested in minimising
> friction for existing users who still prefer the current default,
> or for new users who are probably used to the behaviour of other
> text-editors.

Exactly the same reasoning was presented in arguments against
turning on `transient-mark-mode' by default. That change took
decades. I expect that turning on `delete-selection-mode' by
default (in effect, the other half of the same general change)
will also take decades. I'm convinced it will happen, but perhaps
after some of us are long gone. ;-)

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

[Yuri Khan]

On Fri, Sep 7, 2018 at 10:37 PM Drew Adams <drew.adams@oracle.com> wrote:

> Exactly the same reasoning was presented in arguments against
> turning on `transient-mark-mode' by default.

My experience with other editors says the following three features are
closely related. (The terminology varies from editor to editor, of
course.)


1a) Region selection is persistent. You can mark a region, then move
point outside of it and it stays highlighted and active.

1b) Region selection is transient. As soon as you move point in a way
other than extending selection, it is deactivated.


2a) Newly entered text is inserted at point without affecting the
selected region, whether or not it is active. Backspace and Delete
keys affect the characters before and after point.

2b) Newly entered text replaces the selected region. Backspace and
Delete keys delete the selected region.


3a) You select a region by pressing a key (or key combination or
sequence), at one end, then moving point to the other end and pressing
another key there.

3b) You select a region by moving point with Shift held down.


Many “classic” editors had [1a, 2a, 3a]. Most “modern” editors have
[1b, 2b, 3b]. These two combinations are consistent and useful. Mixing
and matching may feel weird and/or invite mistakes.

E.g., mixing 1a with 2b, you can have a persistent region, then move
point so that you no longer see the region, so you effectively forget
you have an active region. Then, typing new text and having it replace
the region is surprising, in a bad way.

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 (WAS: Some developement questions)

[Clément Pit-Claudel]

On 2018-09-09 09:45, Alan Mackenzie wrote:
> 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.

Careful with this though.  It's easy to misread a moderate response backed by strong feelings and classify it as "don't care too much".

> 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.
Here's a different take on the same observation: people who don't like delete-selection-mode seem to care very much, so we can assume they'll make the effort to turn it off.  Conversely, people who do like it seem to like it only a little, so we can't assume they'll trouble themselves to find the right setting and toggle it.  Hence, it should be enabled by default :)

I don't trust user polls much, FWIW.  They're heavily biased, and people are not good judges of what makes them productive.

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

[Drew Adams]

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

Why "irretrievably"? What happens if you hit `C-w' by mistake?
Do you lose the cut text irretrievably?

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

You conceive of the action in question as being just to insert
a character. But if the region is active and d-s-m is on then
the action is replace the region with the character.

Who controls whether the action is to do one or the other?
You do, by activating or not activating the region. Your choice.
Nothing requires you to activate the region and then insert
the char. You can insert it without activating the region first.

With `transient-mark-mode' came the concept and behavior
of an active region. Emacs is great by having a region that
can be either inactive or active. You can still use an inactive
region (as I'm sure you know and do), so perhaps "active"
is a bit of a misnomer.

The point of activating the region is to act on it. One way
of acting on it is to replace it, and when d-s-m is on that
can happen by yanking or typing replacement text.

Who controls whether the region is active? You do.
Who controls whether and how to act on the active
region? You do. Who controls whether d-s-m is on
or off? You do.

If someone wants to complain about a command
unnecessarily doing two things ("side effect") then s?he
could start by blaming `C-x C-x'. Why does it not only
swap point and mark but also activate the region?

The answer, no doubt, is that someone (who introduced
t-m-m and region "activation") thought that's handy behavior
(saves a keystroke).

Exactly the same kind of handiness comes from d-s-m
performing an implicit `C-w' (for most commands, although
that's configurable per command).

> As well as being bad UI, it violates the "do one thing and
> do it well" principle.

Tell that to `C-x C-x' ;-). And to any number of other Emacs
commands - maybe most!

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

Where's the poll, BTW? I fully expect support for d-s-m to lose
the vote at this point (but not in a few decades ;-)), but I support
taking a poll. It should of course be a user poll, not just a poll of
this mailing list.

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)

[Phil Sainty]

On 2018-09-10 10:24, Drew Adams wrote:
> 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.)

Undo isn't *necessarily* enabled in all buffers?

i.e. `buffer-disable-undo'.

That's not so common, but IIRC some buffers are set that way by
default?


-Phil

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

[Drew Adams]

> > 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.)
> 
> Undo isn't *necessarily* enabled in all buffers?
> i.e. `buffer-disable-undo'.
> 
> That's not so common, but IIRC some buffers are set that way by
> default?

Yes, good point. 

The same problem will exist for accidental `C-w', but yes.

Most delete-selection deletions are kills, so another retrieval
possibility is `C-y'. But I'm sure there are cases where text could
be lost.

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)

[Clément Pit-Claudel]

On 2018-09-10 14:16, Alan Mackenzie wrote:
> 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

I did, in a previous message :) See below:

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

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

[Alan Mackenzie]

Hello, Clément.

On Mon, Sep 10, 2018 at 14:35:17 -0400, Clément Pit-Claudel wrote:
> On 2018-09-10 14:16, Alan Mackenzie wrote:
> > 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

> I did, in a previous message :) See below:

Acknowledged, thanks.

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

This is the "do it because everybody else does" bit.  I don't think it's
a sound design principle, particularly for Emacs.

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

I agree, because ....

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

.... the degree of inconvenience in first having to type C-w, which is
predictable and goes easily to the finger memory is minimal, certainly
when compared with the shock and pain of having an arbitrary sized
region killed without warning.  IMAO, anyway.

-- 
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 (WAS: Some developement questions)

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: joostkremers@fastmail.fm, hw@adminart.net, spacibba@aol.com,
> 	npostavs@gmail.com, emacs-devel@gnu.org,
> 	drew.adams@oracle.com, phillip.lord@russet.org.uk
> Date: Tue, 11 Sep 2018 00:22:18 -0400
> 
> 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.

Shift selection follows a feature of many applications out there, and
AFAIK they all behave with such selections as with mouse selections.
It is actually a more fine-grained selection mechanism, since mouse
selection frequently doesn't let you select partial words, or exclude
punctuation from the selection, at least not easily.

So I think we don't need a separate option for shift selection, it
already behaves like those who use it expect.

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

  > So I think we don't need a separate option for shift selection,

If treating it like mouse selection makes people happy, fine with me.


-- 
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 (WAS: Some developement questions)

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Tue, 11 Sep 2018 00:22:18 -0400
> Cc: hw@adminart.net, spacibba@aol.com, joostkremers@fastmail.fm,
> 	npostavs@gmail.com, emacs-devel@gnu.org, drew.adams@oracle.com,
> 	phillip.lord@russet.org.uk
> 
> 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.

Can you tell why you need it active and highlighted?  Because
otherwise, this is tantamount to turning off transient-mark-mode.

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 is active.
  > >   * It is highlighted.
  > >   * DEL does not delete it.
  > >   * self-insert does not delete it.

  > Can you tell why you need it active and highlighted?  Because
  > otherwise, this is tantamount to turning off transient-mark-mode.

It has to be active because C-x C-x is the way to activate the region
without changing it.

C-x C-x is also a way to make the region highlighted.
-- 
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 (WAS: Some developement questions)

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: hw@adminart.net, spacibba@aol.com, joostkremers@fastmail.fm,
> 	npostavs@gmail.com, emacs-devel@gnu.org,
> 	drew.adams@oracle.com, phillip.lord@russet.org.uk
> Date: Tue, 11 Sep 2018 20:33:05 -0400
> 
>   > >   * It is active.
>   > >   * It is highlighted.
>   > >   * DEL does not delete it.
>   > >   * self-insert does not delete it.
> 
>   > Can you tell why you need it active and highlighted?  Because
>   > otherwise, this is tantamount to turning off transient-mark-mode.
> 
> It has to be active because C-x C-x is the way to activate the region
> without changing it.
> 
> C-x C-x is also a way to make the region highlighted.

I guess I didn't explain myself clearly enough.  What I was asking was
why you need the region active? what features you want to use require
that the region be active? what will you miss if "C-x C-x", "C-SPC
M-f" etc. will not activate the region?

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 (WAS: Some developement questions)

[Drew Adams]

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

FWIW, that's not my case. My case is the opposite: I was used
to "old" Emacs, e.g., pre transient-mark-mode. When
`delete-selection-mode' came along I tried it and appreciated
it immediately. I had no problem getting used to it. Dunno why.

Perhaps simultaneously, or soon thereafter, I started to use
other apps that had similar behavior. But I did not use them
before using `d-s-m' in Emacs. I used `d-s-m' long before I ever
used Emacs on MS Windows, for example.

Anyway, I think you're right about most other people who
use `d-s-m'. It's likely that they got used to the behavior first
outside Emacs. That's probable, simply because many users
came to Emacs later and the behavior was already ubiquitous
outside Emacs.

> They have two possible paths to follow: get used to Emacs,

"Get used to Emacs" has nothing to do with it. That's almost
insulting, I think.

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

I think that's an awful way to express it. What is "Emacs",
that these people supposedly don't want to get used to?

Emacs to me includes `d-s-mode'. To me, it's just as
(un)reasonable to say that those who don't want `d-s-m' to
be the default "don't want to get used to Emacs." Neither
makes sense.

This is not about assimilating immigrants to some
dominant culture, and bothering over the question
about what to do with those who just "don't want to get
used to it" - whether to give them tourist visas, make their
short stays comfortable, and not make them adapt.

That's the wrong way to look at this, IMO, but that's kind
of what I hear you suggesting. (But I hope I'm wrong, and
this does really surprise me coming from you, who have
typically taken a very positive and fair moral stance.)

> rather than those who want to get used to Emacs,
> and also at the expense of experienced Emacs users.

I don't think either default behavior would be at the
expense of experienced Emacs users. It's trivial to set
one's preference about this in an init file. I've been
doing it for decades. Not a big deal.

This is only about what the default behavior should be.
That should have no effect on experienced Emacs users.

It's not helpful, I think, to cast this as being about people
who do or don't "want to get used to Emacs." Putting it
that way betrays, at best, a misunderstanding, I think.

I vote for making `d-s-m' the default because I think it
makes Emacs better - like `transient-mark-mode'.

Can't people just opt into it? Sure, and that's been the
case for years. It will likely remain the case for many
more years, I expect.

Why make it the default? No great reason, I think. More
people are likely to "get used to Emacs with it". More
existing Emacs users are likely to make use of it (maybe).
But there's no _compelling_ reason to turn it on - or off -
by default, IMO.

> I am against making delete-selection-mode the default.

Got it. And I am for it.

(I wonder where we each stood initially when the question
was raised about turning on `transient-mark-mode'?)

It's fine and normal for different people to feel differently
about such things, and even to feel strongly.

I feel (fairly) strongly that `cua-mode' should not be turned
on by default, for instance. But most of the same arguments
that some are making here for `d-s-m' have been made also
for `cua-mode'.

To me, those two are very different, especially wrt how
they affect the rest of Emacs. `d-s-m' has little to no effect
on the use of other keys etc. `cua-mode' conflicts deeply
with much of the rest of Emacs (IMO).

That's why my arguments for turning on `d-s-m' by default
don't focus on most people being already used to that
behavior, from outside Emacs.

That's the most common argument here in favor of `d-s-m',
but it's not mine. I think it is good behavior, and good
especially for Emacs. I picked it up after using Emacs for
years without it - because I found it helpful.

That it facilitates going back and forth between Emacs and
other apps is a nice thing, but it's no compelling argument.

`cua-mode' would also make it easier to go back and forth,
and I'm against that. Does it sometimes trip me up inside
Emacs or outside it, when I try to use `C-s' or `C-f' mistakenly?
Yup. But I still don't want to use `cua-mode' in Emacs, and
I still don't think it should be turned on by default.

Just one opinion.

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

[Ergus]

On Sat, Sep 08, 2018 at 07:54:18AM -0700, Drew Adams wrote:
>> 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.
>
>FWIW, that's not my case. My case is the opposite: I was used
>to "old" Emacs, e.g., pre transient-mark-mode. When
>`delete-selection-mode' came along I tried it and appreciated
>it immediately. I had no problem getting used to it. Dunno why.
>
>Perhaps simultaneously, or soon thereafter, I started to use
>other apps that had similar behavior. But I did not use them
>before using `d-s-m' in Emacs. I used `d-s-m' long before I ever
>used Emacs on MS Windows, for example.
>
>Anyway, I think you're right about most other people who
>use `d-s-m'. It's likely that they got used to the behavior first
>outside Emacs. That's probable, simply because many users
>came to Emacs later and the behavior was already ubiquitous
>outside Emacs.
>
>> They have two possible paths to follow: get used to Emacs,
>
>"Get used to Emacs" has nothing to do with it. That's almost
>insulting, I think.
>
>> 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,
>
>I think that's an awful way to express it. What is "Emacs",
>that these people supposedly don't want to get used to?
>
>Emacs to me includes `d-s-mode'. To me, it's just as
>(un)reasonable to say that those who don't want `d-s-m' to
>be the default "don't want to get used to Emacs." Neither
>makes sense.
>
>This is not about assimilating immigrants to some
>dominant culture, and bothering over the question
>about what to do with those who just "don't want to get
>used to it" - whether to give them tourist visas, make their
>short stays comfortable, and not make them adapt.
>
>That's the wrong way to look at this, IMO, but that's kind
>of what I hear you suggesting. (But I hope I'm wrong, and
>this does really surprise me coming from you, who have
>typically taken a very positive and fair moral stance.)
>
>> rather than those who want to get used to Emacs,
>> and also at the expense of experienced Emacs users.
>
>I don't think either default behavior would be at the
>expense of experienced Emacs users. It's trivial to set
>one's preference about this in an init file. I've been
>doing it for decades. Not a big deal.
>
>This is only about what the default behavior should be.
>That should have no effect on experienced Emacs users.
>
>It's not helpful, I think, to cast this as being about people
>who do or don't "want to get used to Emacs." Putting it
>that way betrays, at best, a misunderstanding, I think.
>
>I vote for making `d-s-m' the default because I think it
>makes Emacs better - like `transient-mark-mode'.
>
>Can't people just opt into it? Sure, and that's been the
>case for years. It will likely remain the case for many
>more years, I expect.
>
>Why make it the default? No great reason, I think. More
>people are likely to "get used to Emacs with it". More
>existing Emacs users are likely to make use of it (maybe).
>But there's no _compelling_ reason to turn it on - or off -
>by default, IMO.
>
>> I am against making delete-selection-mode the default.
>
>Got it. And I am for it.
>
>(I wonder where we each stood initially when the question
>was raised about turning on `transient-mark-mode'?)
>
>It's fine and normal for different people to feel differently
>about such things, and even to feel strongly.
>
>I feel (fairly) strongly that `cua-mode' should not be turned
>on by default, for instance. But most of the same arguments
>that some are making here for `d-s-m' have been made also
>for `cua-mode'.
>
>To me, those two are very different, especially wrt how
>they affect the rest of Emacs. `d-s-m' has little to no effect
>on the use of other keys etc. `cua-mode' conflicts deeply
>with much of the rest of Emacs (IMO).
>
>That's why my arguments for turning on `d-s-m' by default
>don't focus on most people being already used to that
>behavior, from outside Emacs.
>
>That's the most common argument here in favor of `d-s-m',
>but it's not mine. I think it is good behavior, and good
>especially for Emacs. I picked it up after using Emacs for
>years without it - because I found it helpful.
>
>That it facilitates going back and forth between Emacs and
>other apps is a nice thing, but it's no compelling argument.
>
>`cua-mode' would also make it easier to go back and forth,
>and I'm against that. Does it sometimes trip me up inside
>Emacs or outside it, when I try to use `C-s' or `C-f' mistakenly?
>Yup. But I still don't want to use `cua-mode' in Emacs, and
>I still don't think it should be turned on by default.
>
>Just one opinion.
>

I agree because cua-mode is very intrusive with the normal emacs
workflow, but on the other had cua-rectangle-mode is not and it is not
by default in emacs (I can't really understand why) and the default
rectangle selection is very primitive.

The actual C-x SPC rectangle selection is not as good as cua-rectangle
selection in any sense and duplicated functionalities that where already
there, it is not possible to move the rectangle or change the rectangle
selection to global selection, and for copy/paste/edit it requires extra
commands with C-x r prefix.

Cua-rectangle-mode offers exactly the same functionalities without the
C-x r prefix, plus commands like rectangle selection, edition and move
out of the box with no extra commands and not changing the emacs
behavior. I think this is one example where the default behavior it much
more primitive than the default one for not real reason.

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

[Clément Pit-Claudel]

On 2018-09-08 01:13, Richard Stallman wrote:
> 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 that might be begging the question, actually.  Or, at least, this argument can be applied to any Emacs default, if that default doesn't align with what other editors do.

In other words, sufficiently proficient users of Emacs will get used to all of its defaults, or change them.  That doesn't mean that they are all good defaults. 

delete-selection-mode might be a good default; I don't know. I tend to think that we should only diverge from the behavior of other programs if it yields significant benefits.  I see lossless undo, kill ring, undo-in-region, and many other features as yielding significant benefits, worth the divergence from other more typical behavior.  I don't see delete-selection-mode being off in the same way.  That could be because I don't see all that it offers.

Clément.

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)

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 (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 (WAS: Some developement questions)

[Eli Zaretskii]

> Date: Sat, 08 Sep 2018 09:19:21 +0530
> From: Bingo <right.ho@gmail.com>
> 
> 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 : 

What problems will such a change solve?

Personally, I think that changing the behavior just because there's an
init file, even though that init file doesn't explicitly mention the
affected features, would be confusing.

More importantly, I think the argument about the defaults, at least
for veteran Emacs users matters mainly when there is no init file
anyway.

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

So I guess you are saying delete-selection-mode should not be turned
on by default?  If so, why do we need the change you propose?

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

[Bingo]

Le 8 septembre 2018 12:53:46 GMT+05:30, Eli Zaretskii <eliz@gnu.org> a écrit :
>> Date: Sat, 08 Sep 2018 09:19:21 +0530
>> From: Bingo <right.ho@gmail.com>
>> 
>> 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 : 
>
>What problems will such a change solve?
>
>Personally, I think that changing the behavior just because there's an
>init file, even though that init file doesn't explicitly mention the
>affected features, would be confusing.
>
>More importantly, I think the argument about the defaults, at least
>for veteran Emacs users matters mainly when there is no init file
>anyway.

I mean :

1. When Emacs first starts, see if there is an init file. Various modern software do so, so we would be on solid ground there.

2. If so, trust the user that he would have set delete-selection-mode as required. This would avoid stepping on the toes of power users : which form the majority of Emacs users.

3. If not, create an init file with these "modern" options. This can attract the new users we want. Modern software create a lot of files and registry entries for cache and config, no one would blame 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.
>
>So I guess you are saying delete-selection-mode should not be turned
>on by default?  If so, why do we need the change you propose?

Personally, I would rather delete-selection-mode not be on by default. But I know nothing about what is good for new users. If it must be turned on, maybe people with init files can be spared ?


Thanks a lot

Hi Eli, clarified inline :

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

[Eli Zaretskii]

> Date: Sat, 08 Sep 2018 14:03:46 +0530
> CC: emacs-devel@gnu.org
> From: Bingo <right.ho@gmail.com>
> 
> 1. When Emacs first starts, see if there is an init file. Various modern software do so, so we would be on solid ground there.
> 
> 2. If so, trust the user that he would have set delete-selection-mode as required.

I'm not sure this is a valid assumption.  A user could have
delete-selection-mode not turned on because she had no idea such a
thing existed in Emacs.

>  This would avoid stepping on the toes of power users : which form the majority of Emacs users.

Please note that veteran users only care about defaults when they need
to use Emacs on someone else's machine, or when logged on as some
other user (like root or su).

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

[Alan Mackenzie]

Hello, Eli.

On Sat, Sep 08, 2018 at 12:26:43 +0300, Eli Zaretskii wrote:
> > Date: Sat, 08 Sep 2018 14:03:46 +0530
> > CC: emacs-devel@gnu.org
> > From: Bingo <right.ho@gmail.com>

> > 1. When Emacs first starts, see if there is an init file. Various
> > modern software do so, so we would be on solid ground there.

> > 2. If so, trust the user that he would have set delete-selection-mode
> > as required.

> I'm not sure this is a valid assumption.  A user could have
> delete-selection-mode not turned on because she had no idea such a
> thing existed in Emacs.

> >  This would avoid stepping on the toes of power users : which form
> >  the majority of Emacs users.

> Please note that veteran users only care about defaults when they need
> to use Emacs on someone else's machine, or when logged on as some other
> user (like root or su).

A third situation, in which at least one veteran user (me) cares is when
testing a bug fix with emacs -Q.  In such cases, I can get fairly
irritated by, e.g., transient-mark-mode, and would get even more
irritated were delete-selection-mode to be enabled by default.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Drew Adams]

> A third situation, in which at least one veteran user (me) cares is when
> testing a bug fix with emacs -Q.  In such cases, I can get fairly
> irritated by, e.g., transient-mark-mode, and would get even more
> irritated were delete-selection-mode to be enabled by default.

I don't understand. If it were on by default then to repro the
user's recipe from emacs -Q you would want to have it on, no?

Even now, when it is not on by default, if a user recipe to repro
it says to turn on d-s-m you would do that, no?

Are you saying that it would annoy you to follow a user's recipe?

Yes, if it were on by default then more bug recipes would have
it on than off, on average. And if you were to follow a recipe
with it on then you might be annoyed - as you are now by
t-m-m being on in most recipes.

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

[Eli Zaretskii]

> Date: Sun, 9 Sep 2018 13:13:16 +0000
> Cc: Bingo <right.ho@gmail.com>, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > Please note that veteran users only care about defaults when they need
> > to use Emacs on someone else's machine, or when logged on as some other
> > user (like root or su).
> 
> A third situation, in which at least one veteran user (me) cares is when
> testing a bug fix with emacs -Q.

Yes, of course.  Same here.

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

[Ergus]

On Sun, Sep 09, 2018 at 01:13:16PM +0000, Alan Mackenzie wrote:
>Hello, Eli.
>
>On Sat, Sep 08, 2018 at 12:26:43 +0300, Eli Zaretskii wrote:
>> > Date: Sat, 08 Sep 2018 14:03:46 +0530
>> > CC: emacs-devel@gnu.org
>> > From: Bingo <right.ho@gmail.com>
>
>> > 1. When Emacs first starts, see if there is an init file. Various
>> > modern software do so, so we would be on solid ground there.
>
>> > 2. If so, trust the user that he would have set delete-selection-mode
>> > as required.
>
>> I'm not sure this is a valid assumption.  A user could have
>> delete-selection-mode not turned on because she had no idea such a
>> thing existed in Emacs.
>
>> >  This would avoid stepping on the toes of power users : which form
>> >  the majority of Emacs users.
>
>> Please note that veteran users only care about defaults when they need
>> to use Emacs on someone else's machine, or when logged on as some other
>> user (like root or su).
>
>A third situation, in which at least one veteran user (me) cares is when
>testing a bug fix with emacs -Q.  In such cases, I can get fairly
>irritated by, e.g., transient-mark-mode, and would get even more
>irritated were delete-selection-mode to be enabled by default.
>
>-- 
>Alan Mackenzie (Nuremberg, Germany).
>

I understand this. But then I only see 2 possible solutions:

1) Keep emacs defaults only for experienced users, so forget about getting new users and let it die slowly.

2) Start thinking in the new generations who will inherit emacs but already have a standard idea of how editors should behave; very different of the emacs defaults.

As a good consensus (and we are again where this thread started) is the
option to make an initial assistant (like the one in spacemacs but maybe
more complete) which can provide a bunch of options to the user to
set/unset them (with some information or more options depending of the
user (it can start with standard, advanced, minimal like many other
programs)). And add this configuration as the init file (if there was
not one) or as an extra file that cannot be skipped with -Q but with
another option that could be added.

This is maybe a bit more complicated to implement, but it can satisfy both cases somehow.

There is a point where old projects need to adapt themselves to the
running times, not only importing functionalities, but also updating
functionalities they already have in order to improve them. But we need
to think in the normal users which are majority in any project.

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

[Alan Mackenzie]

Hello, Ergus.

On Sun, Sep 09, 2018 at 19:59:53 +0200, Ergus wrote:

> On Sun, Sep 09, 2018 at 01:13:16PM +0000, Alan Mackenzie wrote:
> >Hello, Eli.

> >On Sat, Sep 08, 2018 at 12:26:43 +0300, Eli Zaretskii wrote:
> >> > Date: Sat, 08 Sep 2018 14:03:46 +0530
> >> > CC: emacs-devel@gnu.org
> >> > From: Bingo <right.ho@gmail.com>

> >> > 1. When Emacs first starts, see if there is an init file. Various
> >> > modern software do so, so we would be on solid ground there.

> >> > 2. If so, trust the user that he would have set delete-selection-mode
> >> > as required.

> >> I'm not sure this is a valid assumption.  A user could have
> >> delete-selection-mode not turned on because she had no idea such a
> >> thing existed in Emacs.

> >> >  This would avoid stepping on the toes of power users : which form
> >> >  the majority of Emacs users.

> >> Please note that veteran users only care about defaults when they need
> >> to use Emacs on someone else's machine, or when logged on as some other
> >> user (like root or su).

> >A third situation, in which at least one veteran user (me) cares is when
> >testing a bug fix with emacs -Q.  In such cases, I can get fairly
> >irritated by, e.g., transient-mark-mode, and would get even more
> >irritated were delete-selection-mode to be enabled by default.

> >-- 
> >Alan Mackenzie (Nuremberg, Germany).


> I understand this. But then I only see 2 possible solutions:

> 1) Keep emacs defaults only for experienced users, so forget about
> getting new users and let it die slowly.

Emacs is over 40 years old, and has seen many fads come and go.  It has
been steadily acquiring new users in that time, and losing old ones.  As
a program it combines extreme user friendliness with a long steep
learning curve (i.e. it is not "beginner friendly").  I don't think we
should be trying to change these attributes.

> 2) Start thinking in the new generations who will inherit emacs but
> already have a standard idea of how editors should behave; very
> different of the emacs defaults.

Many of them, faced with a choice between lots of clones which behave in
a beginner-friendly, but suboptimal fashion, and the freshness of Emacs
will come to chose Emacs.  We should not deprive them of this choice by
dumbing down Emacs.

Incidentally, the current discussion, in essence, has been going on on
this list for the last 20 years or so, and probably quite a bit longer.

> As a good consensus (and we are again where this thread started) is the
> option to make an initial assistant (like the one in spacemacs but maybe
> more complete) which can provide a bunch of options to the user to
> set/unset them (with some information or more options depending of the
> user (it can start with standard, advanced, minimal like many other
> programs)). And add this configuration as the init file (if there was
> not one) or as an extra file that cannot be skipped with -Q but with
> another option that could be added.

I suggested something similar some years ago, but never got around to
implementing it: that there be several sets of defaults, and a user
choses a set of defaults by the name of the command she starts Emacs
with: for example, I would start emacs-classic, whereas you would start
something like emacs-cua.  This could be implemented by hard links, with
the Emacs binary finding its "pre-"initialisation file by checking the
name it was invoked by.  Or something like that.

> This is maybe a bit more complicated to implement, but it can satisfy
> both cases somehow.

> There is a point where old projects need to adapt themselves to the
> running times, .....

You have to be careful that this doesn't mean dumbing down.

> .... not only importing functionalities, but also updating
> functionalities they already have in order to improve them. But we need
> to think in the normal users which are majority in any project.

As a counterexample to your argument, look at the inconsistent series of
messes that recent versions of Firefox have become.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Ergus]

On Sun, Sep 09, 2018 at 07:12:53PM +0000, Alan Mackenzie wrote:

Hello Alan:
>Hello, Ergus.
>
>On Sun, Sep 09, 2018 at 19:59:53 +0200, Ergus wrote:
>
>> On Sun, Sep 09, 2018 at 01:13:16PM +0000, Alan Mackenzie wrote:
>> >Hello, Eli.
>
>> >On Sat, Sep 08, 2018 at 12:26:43 +0300, Eli Zaretskii wrote:
>> >> > Date: Sat, 08 Sep 2018 14:03:46 +0530
>> >> > CC: emacs-devel@gnu.org
>> >> > From: Bingo <right.ho@gmail.com>
>
>> >> > 1. When Emacs first starts, see if there is an init file. Various
>> >> > modern software do so, so we would be on solid ground there.
>
>> >> > 2. If so, trust the user that he would have set delete-selection-mode
>> >> > as required.
>
>> >> I'm not sure this is a valid assumption.  A user could have
>> >> delete-selection-mode not turned on because she had no idea such a
>> >> thing existed in Emacs.
>
>> >> >  This would avoid stepping on the toes of power users : which form
>> >> >  the majority of Emacs users.
>
>> >> Please note that veteran users only care about defaults when they need
>> >> to use Emacs on someone else's machine, or when logged on as some other
>> >> user (like root or su).
>
>> >A third situation, in which at least one veteran user (me) cares is when
>> >testing a bug fix with emacs -Q.  In such cases, I can get fairly
>> >irritated by, e.g., transient-mark-mode, and would get even more
>> >irritated were delete-selection-mode to be enabled by default.
>
>> >--
>> >Alan Mackenzie (Nuremberg, Germany).
>
>
>> I understand this. But then I only see 2 possible solutions:
>
>> 1) Keep emacs defaults only for experienced users, so forget about
>> getting new users and let it die slowly.
>
>Emacs is over 40 years old, and has seen many fads come and go.  It has
>been steadily acquiring new users in that time, and losing old ones.  As
>a program it combines extreme user friendliness with a long steep
>learning curve (i.e. it is not "beginner friendly").  I don't think we
>should be trying to change these attributes.
>
I partially agree because the project survived more or less
actively. But in the last 10 years the use have strongly declined.

The first 20 years emacs adapted to changes very quickly, changing
details, architectures, adopting gui, extending. After the 2000 appeared
many other editors and they more or less standardized what text editing
is. But also other factors affected the emacs extension like the
ubiquity of windows, notepad++ (with almost not learning curve), emacs
not being installed by default in the GNU/Linux distributions. So emacs
keeps a number of users like in the 90s while now the number of
programmers and developers in the world is orders of magnitude higher.
And we did nothing.

>> 2) Start thinking in the new generations who will inherit emacs but
>> already have a standard idea of how editors should behave; very
>> different of the emacs defaults.
>
>Many of them, faced with a choice between lots of clones which behave in
>a beginner-friendly, but suboptimal fashion, and the freshness of Emacs
>will come to chose Emacs.  We should not deprive them of this choice by
>dumbing down Emacs.
>
>Incidentally, the current discussion, in essence, has been going on on
>this list for the last 20 years or so, and probably quite a bit longer.
>
The point is that emacs can bring the same experience than any other
editor just some configuration (projects like spacemacs proves
this). But the default experience is too different that most users feel
scared and move to something "simpler". And we do nothing to avoid this;
stating with the tutorial or the online documentation (where 99% of the
users look for stuff and not in the self documentation, stackoverflow
success is the prove that nobody reads the manuals or the full
documentation in our days). 

There is not an interactive foro where users can make questions and
answer each other actively, and if the emacswiki is not updated in many
articles is a prove that we don't have enough users proportional to the
projects' dimension.  Add to this that many packages and functionalities
are duplicated in different packages and the user gets confused and some
packages in the repositories are unmaintained since 5 years or more.

Looking how the number of sublime text users grew in 2 years shows all
the users that emacs is loosing just for not bringing an initial good
face. Because Sublime is not superior to emacs in any sense, except the
behavior that is "like expected".

>> As a good consensus (and we are again where this thread started) is the
>> option to make an initial assistant (like the one in spacemacs but maybe
>> more complete) which can provide a bunch of options to the user to
>> set/unset them (with some information or more options depending of the
>> user (it can start with standard, advanced, minimal like many other
>> programs)). And add this configuration as the init file (if there was
>> not one) or as an extra file that cannot be skipped with -Q but with
>> another option that could be added.
>
>I suggested something similar some years ago, but never got around to
>implementing it: that there be several sets of defaults, and a user
>choses a set of defaults by the name of the command she starts Emacs
>with: for example, I would start emacs-classic, whereas you would start
>something like emacs-cua.  This could be implemented by hard links, with
>the Emacs binary finding its "pre-"initialisation file by checking the
>name it was invoked by.  Or something like that.
>
>> This is maybe a bit more complicated to implement, but it can satisfy
>> both cases somehow.
>
>> There is a point where old projects need to adapt themselves to the
>> running times, .....
>
>You have to be careful that this doesn't mean dumbing down.
>
OK, but it doesn't mean that everything should be frozen and unchanged
because it works as it is. Maybe is can be better, or in general the
users prefer that way (there should be a reason); and the project is not
only for it's developers.

Have you ever think why there are so many sublime text users?

>> .... not only importing functionalities, but also updating
>> functionalities they already have in order to improve them. But we need
>> to think in the normal users which are majority in any project.
>
>As a counterexample to your argument, look at the inconsistent series of
>messes that recent versions of Firefox have become.
>
Yes, But Firefox lost like the 70% of its users in 5 years because they
offered the same experience but the rest of the world moved on, so they
just tried to fix the issues they had with speed and memory usage. They
also have the chrome competition and they depend of web architectures
and interfaces that evolves constantly. So the comparison is not
parallel with emacs from my point of view.

But, as a consequence of latest changes, many chrome, chromium, and
Opera users moved back to Firefox again. Plugins started to be
maintained again, there are some more contributors now. If they had made
the changes gradually among the years maybe some users keep there but
also the changes had been not so drastic and the users had time to
adapt. In general the project has more live now, in spite of the
problems associated with any big change. And actually Firefox works
better now than before Quantum, specially in mobile.
>-- 
>Alan Mackenzie (Nuremberg, Germany).

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

[Drew Adams]

> But the default experience is too different that most users feel
> scared and move to something "simpler". And we do nothing to avoid this;
> stating with the tutorial or the online documentation (where 99% of the
> users look for stuff and not in the self documentation, stackoverflow
> success is the prove that nobody reads the manuals or the full
> documentation in our days).

It's true that many users, particularly younger ones, do not look
first (or much) to the documentation these days. This is true
generally, not just for Emacs. It seems quicker and easier to
google, watch a video, or ask a question on a Q&A site.

That's not a reason not to continue having great documentation,
IMO. And the fact that a new Emacs user won't necessarily think
of or learn about `C-h m' etc. is not a reason not to continue to
have great doc strings and help commands.

And often the ultimate result of googling or posing a question
here or there is to end up at an Emacs manual. IOW, there needs
to be some real meat-and-bones content somewhere. And for
Emacs the main repositories of such content are (1) the code
itself, (2) the Emacs manual, and (3) the Elisp manual. (And
other Emacs manuals, such as Org.)

On sites like emacs.stackexchange, while providing an answer
to a question I, and others, generally try to also teach how to
ask questions of Emacs itself, including the help commands
and how to use the manual efficiently.

Emacs is different from many interactive interfaces for
developers in being particularly helpful and discoverable.
There's room for improvement, of course.

But the fact that new Emacs users might not know that
such self-help exists represents an opportunity to make it
more apparent. It's not a reason to put less emphasis on
the help and doc.

> There is not an interactive foro where users can make questions and
> answer each other actively, 

There are several, I think, from discussion sites such as reddit
to Q&A sites such as emacs.stackexchange. There is no GNU
forum, I guess. But I'm not convinced there needs to be one.

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

  > 1. Emacs undo is frustrating for most new users.

If that is true, it is an important issue.
What evidence is there for that statement?
If so, do we know why it is so?

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