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

[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 (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 (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)

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

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

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

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

[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 (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)

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

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

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

[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 (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)

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

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

[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 (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 (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 (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)

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

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)

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

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

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

Emacs undo behavior frustrating for new users. (WAS: delete-selection-mode as default)

[Karl Fogel]

Richard Stallman <rms@gnu.org> writes:
>  > 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?

Here is an answer from my friend Noel, who was recently a new user of Emacs.  (He still uses Emacs, he's just no longer a new user.)  When I saw your question above, I remembered Noel's frustration with Emacs's default undo behavior when he was learning Emacs, and I asked him if he'd be willing to write it up.

I've CC'd him here, so he can participate in any followup discussion.

> From: Noel Taylor <noeltaylo@gmail.com>
> Subject: why emacs undo behavior can be confusing to new users
> To: Karl Fogel <kfogel@red-bean.com>
> Date: Sun, 14 Oct 2018 01:32:52 -0500
> 
> To whom it may be of interest:
> 
> There are differences between the "undo" function of emacs and that
> of most other programs that may be confusing, and potentially
> frustrating, to new users.
> 
> There are, of course, countless programs with an "undo" feature, but
> in my personal experience, the "undo" behavior of emacs is unique.
> Every other program I can recall using, from Microsoft Word to Gmail
> to any web browser with "back" and "forward" buttons - if it has an
> "undo" function at all - has implemented "undo" in the same way, and
> I posit that many newcomers to emacs will be surprised that "undo" in
> emacs does not behave as it does in these other programs.
> 
> In the following paragraphs I will use the term "MS Word user" to
> refer to a person who is familiar with the "undo" behavior of other
> programs but who is new to emacs.
> 
> THE FUNDAMENTAL DESIGN DIFFERENCE:
> 
> The fundamental difference between the "undo" behavior of emacs and
> that of other programs is that other programs have separate "undo"
> and "redo" functions that act as a kind of temporal scroll bar,
> moving the document back and forth in time as the physical scroll bar
> moves it up and down in space. Emacs, by contrast, really only has
> "undo", and it does not slide the document back in time so much as it
> recovers a previous state of the document and copies it into the
> present. This difference in design is ultimately at the root of the
> confusion for new users of emacs, and it manifests in two main
> behaviors.
> 
> BEHAVIOR # 1
> 
> The most immediately noticeable way in which the undo behavior of
> emacs differs from that of MS Word and other programs is that
> "undoing" something in those other programs is not itself an undoable
> action. As such, the chain of undoable / redoable actions (let's call
> it the "action history") can - and frequently does - become shorter,
> whereas in emacs it normally only grows longer.
> 
> For example, in MS Word, if a user performs actions A, B, C, and D,
> and then undoes the last two actions, they will be returned to a
> state in which only A and B have been performed. If the user then
> performs a new action E, the actions C and D will be lost, and the
> new action history will comprise only actions A, B, and E.
> 
> This behavior may seem inherently undesirable in a text editor, but
> the MS Word user expects and even relies on it, as they are
> accustomed to maintaining a mental model of their action history as
> they edit their document, and the "undo" and "redo" actions can help
> them with this.
> 
> The MS Word user is used to being able to traverse their action
> history without the traversal itself having any effect.  Again, in MS
> Word, if a user performs actions A, B, C, D, and E, they can use undo
> and redo to move back and forth between A and D, between B and E,
> between A and C, etc. as much as they like. And at the end of all the
> undoing and redoing, their action history will still comprise only
> those five actions.
> 
> If the same user tries this in emacs, they may be surprised to find
> that a point they thought was only a few "undo" actions away now
> takes much longer to reach. If for example, they perform actions A,
> B, C, D, and E:
> 
>     A -> B -> C-> D -> E
> 
> and then "undo" back to point B and *then* "undo undo" back to point
> E again, the MS Word user will imagine their action history as being
> exactly the same as when they originally performed action E, when in
> fact it looks like this:
> 
>     A -> B -> C -> D -> E -> D-> C -> B -> C -> D -> E
> 
> If they then decide they want to return to point A, they will be
> confused that it now takes 10 "undo" actions to get there instead of
> 4 actions. They will also wonder why the buffer seems to be moving
> first backward, then forward, then backward again in time. They may
> even break the undo procedure before they ever reach point A to try
> something else, which only makes point A more remote than before. A
> growing sense of frustration then follows as they continue to undo
> and redo, accustomed as they are to being able to roll back and forth
> without side effects, but instead finding that earlier points they
> thought would be nearby are ever more distant. It has now become
> impossible for them to maintain a mental model of their increasingly
> complicated action history, so they swear, return the buffer to some
> state that is sort-of like what they want, save it to a file, kill
> the buffer, and re-open it, all for the sake of dumping the
> convoluted action history.
> 
> I've been using emacs for years now and even though I am very used to
> its "undo" behavior, I still make frequent use of the following
> addition to my .emacs file:
> 
> (defun forget-undo () "Drop this buffer's undo history."
> (interactive) (setq buffer-undo-list nil))  
> 
> BEHAVIOR # 2
> 
> The other behavior that can be confusing to new users of emacs is
> that if the user is in the process of "undoing" to an earlier point
> in the action history, the act of moving the cursor (for example,
> with the arrow keys) will interrupt the undo sequence even though no
> change has been made to the contents of the buffer.
> 
> MS Word and other programs do not work like this. Actions that do not
> affect the text also do not affect the user's action history. If we
> again assume that the MS Word user has completed actions A, B, C, D,
> and E, and that they have then performed "undo" actions to go from
> point E back to point B, they can move the cursor around all they
> like (which they might do because perhaps it is easier at that moment
> to view a different part of the text by moving the cursor rather than
> by moving a scroll bar), and they can still "fast-forward" again to
> point E.  Merely moving the cursor has not affected their action
> history.
> 
> MS Word and other programs therefore define two kinds of actions:
> those that affect the contents of the text, also causing any
> "forward" history to be lost, and those that do not affect the
> contents of the text, leaving the action history unaffected.
> 
> CONCLUSION
> 
> I hope that I have clearly articulated why the emacs "undo" can be
> confusing to new users. I am not making any claims as to which style
> is better. However, adding the MS-Word-style behavior - with separate
> "undo" and "redo" actions - as a built-in configuration option to
> emacs might make it easier for new users to approach.
> 
> N. Taylor

Re: Emacs undo behavior frustrating for new users.

[Stefan Monnier]

> Here is an answer from my friend Noel, who was recently a new user of Emacs.
> (He still uses Emacs, he's just no longer a new user.)  When I saw your
> question above, I remembered Noel's frustration with Emacs's default undo
> behavior when he was learning Emacs, and I asked him if he'd be willing to
> write it up.

BTW, Emacs does provide the "usual" undo command under the name
`undo-only` (it only affects the way Emacs traverses the undo history,
not the way the undo history is built, so it can be mixed with Emacs's
traditional `undo` just fine).
We could also provide a corresponding `undo-redo` command, which
similarly only performs redo actions.

>> The other behavior that can be confusing to new users of emacs is
>> that if the user is in the process of "undoing" to an earlier point
>> in the action history, the act of moving the cursor (for example,
>> with the arrow keys) will interrupt the undo sequence even though no
>> change has been made to the contents of the buffer.

I've been using here a patch which makes `undo` query the user when this
happens.  More specifically, if you call `undo` when the last buffer
modification was itself an undo but the last command was not an undo, it
prompts the user asking where they want to continue undoing.


        Stefan

Re: Emacs undo behavior frustrating for new users.

[Karl Fogel]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Here is an answer from my friend Noel, who was recently a new user of Emacs.
>> (He still uses Emacs, he's just no longer a new user.)  When I saw your
>> question above, I remembered Noel's frustration with Emacs's default undo
>> behavior when he was learning Emacs, and I asked him if he'd be willing to
>> write it up.
>
>BTW, Emacs does provide the "usual" undo command under the name
>`undo-only` (it only affects the way Emacs traverses the undo history,
>not the way the undo history is built, so it can be mixed with Emacs's
>traditional `undo` just fine).
>We could also provide a corresponding `undo-redo` command, which
>similarly only performs redo actions.

Thanks, Stefan.  I've added Noel Taylor back to CC here, so he sees this too.  (He's not subscribed to this list.)

I didn't know about that command.  I had searched for a variable that would control undo behavior -- I wasn't imaginative enough to guess that it might simply be a separate command, rather than a variable that changes the behavior of the familiar command.

Noel, want to try binding `undo-only' to replace your normal `undo` keybindings and see if that provides a behavior that seems more natural to you?

(And see how much you miss not having `undo-redo'... That probably wouldn't be very hard to implement, but I'm conspicuously not volunteering until we have a sense of how badly it would be missed by someone who is accustomed to having it.)

>>> The other behavior that can be confusing to new users of emacs is
>>> that if the user is in the process of "undoing" to an earlier point
>>> in the action history, the act of moving the cursor (for example,
>>> with the arrow keys) will interrupt the undo sequence even though no
>>> change has been made to the contents of the buffer.
>
>I've been using here a patch which makes `undo` query the user when this
>happens.  More specifically, if you call `undo` when the last buffer
>modification was itself an undo but the last command was not an undo, it
>prompts the user asking where they want to continue undoing.

Interesting!  Is that patch posted (or are you planning to post it after all the kinks get worked out)?

Best regards,
-Karl

Re: Emacs undo behavior frustrating for new users. (WAS: 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 had to hold my nose about the frequent use of sinular "they" in
what your friend sent, but it is very interesting.

I have nothing in principle against switching to an Undo/Redo system.
But there is an obstacle: finding a key for the Redo command.

However, I think this aspect of the behavior is bad:

  > > For example, in MS Word, if a user performs actions A, B, C, and D,
  > > and then undoes the last two actions, [perse] will be returned to a
  > > state in which only A and B have been performed.

A good Undo/Redo system should save the states C and D somewhere and
offer SOME way to get back to them.

  > > MS Word and other programs therefore define two kinds of actions:
  > > those that affect the contents of the text, ... and those that do not affect the
  > > contents of the text, leaving the action history unaffected.

This might be feasible to implement as an option.

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

Re: Emacs undo behavior frustrating for new users.

[Noel Taylor]

> On Oct 14, 2018, at 11:59 PM, Karl Fogel <kfogel@red-bean.com> wrote:
> 
> Noel, want to try binding `undo-only' to replace your normal `undo` keybindings and see if that provides a behavior that seems more natural to you?

Haha not really at this point. I would have loved to in my first few months of using emacs, but by now I don't think it will feel any more natural to me now than it would to you. 

> (And see how much you miss not having `undo-redo'... That probably wouldn't be very hard to implement, but I'm conspicuously not volunteering until we have a sense of how badly it would be missed by someone who is accustomed to having it.)

Ah but I'm long past being accustomed to having it now. If I tried to do my job using the MS Word style undo I'm sure that for me personally - it would be more a hindrance than a help. Such a change could well be useful to new emacs users, but I'm no longer one of those.

But I'm still very glad to learn that "undo-only" exists! Thank you, Stefan for pointing that out. And I will try it out at some point - probably not when I'm using emacs for work though. 

N

Re: Emacs undo behavior frustrating for new users. (WAS: delete-selection-mode as default)

[Van L]

> I have nothing in principle against switching to an Undo/Redo system.
> But there is an obstacle: finding a key for the Redo command.

C-< ;; for Undo
C-> ;; for Redo

The above are undef in Org Mode.

People talk about a Big Refactor of Gnus’s source code.

The most often used key-commands should be heat mapped
and made easily reachable from the homekey row for new
layout to key-commands. For me, modifier+space and then
whatever keysequence follow makesense.

Re: Emacs undo behavior frustrating for new users. (WAS: delete-selection-mode as default)

[Joost Kremers]

On Sun, Oct 14 2018, Karl Fogel wrote:
> Richard Stallman <rms@gnu.org> writes:
>>  > 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?
>
> Here is an answer from my friend Noel, who was recently a new 
> user of Emacs.  (He still uses Emacs, he's just no longer a new 
> user.)  When I saw your question above, I remembered Noel's 
> frustration with Emacs's default undo behavior when he was 
> learning Emacs, and I asked him if he'd be willing to write it 
> up.

Personally, I'm also not very fond of Emacs' standard undo system, 
even though I appreciate the fact that past states of the buffer 
don't get lost, unlike the more common MS-Word undo/redo system. 
It's a little surprising to me, though, that this discussion comes 
up, because I thought the difficulties of Emacs' undo system for 
new users are well-known, and moreover, the solution is already on 
GNU ELPA in the form of the `undo-tree' package: 

<https://elpa.gnu.org/packages/undo-tree.html>

In short, undo-tree gives Emacs the common undo/redo system, but 
with an Emacs twist: instead of a single, linear, history of 
changes, in which previously "undone" states are lost when you 
edit the text in any way, are not lost but stored as separate 
branches. So the history of changes is not a single, linear line, 
it's a tree. One path in this tree is current, meaning undo/redo 
will move over it, but you can switch branches to access states 
that would have been lost by MS Word.

The package comes with a visualiser that shows you the tree and 
that updates the buffer when you walk it, making it very easy to 
get back to any state of the buffer's edit history. It also has 
some other niceties, such as time stamps and diff display.

The beauty of the package is that a new user can simply use 
undo/redo in the way they[1] are familiar with, but the entire 
power of Emacs' undo system is there when needed.

IMvHO `undo-tree' should simply be made the default undo in Emacs.

Joost



[1] Sorry, Richard! :-)

-- 
Joost Kremers
Life has its moments

Re: Emacs undo behavior frustrating for new users. (WAS: delete-selection-mode as default)

[Yuri Khan]

On Mon, Oct 15, 2018 at 12:44 PM Richard Stallman <rms@gnu.org> wrote:

> I have nothing in principle against switching to an Undo/Redo system.
> But there is an obstacle: finding a key for the Redo command.

Simple: C-z for Undo, C-S-z and possibly C-y for Redo, in cua-mode, on
the grounds that these are the most common bindings for this
functionality in pretty much all other software. (C-y will conflict
with yank but cua-mode binds C-v to cua-paste which is a close
analog.)

For text terminal non-cua users, maybe negative universal argument to
the undo command?

Re: Emacs undo behavior frustrating for new users. (WAS: delete-selection-mode as default)

[Joost Kremers]

On Mon, Oct 15 2018, Joost Kremers wrote:
> In short, undo-tree gives Emacs the common undo/redo system, but 
> with an Emacs
> twist: instead of a single, linear, history of changes, in which 
> previously
> "undone" states are lost when you edit the text in any way, are 
> not lost but
__________________________________________________such states^

> stored as separate branches. So the history of changes is not a 
> single, linear
> line, it's a tree. One path in this tree is current, meaning 
> undo/redo will 

-- 
Joost Kremers
Life has its moments

Re: Emacs undo behavior frustrating for new users.

[Óscar Fuentes]

Joost Kremers <joostkremers@fastmail.fm> writes:

[snip]
> the form of the `undo-tree' package: 
>
> <https://elpa.gnu.org/packages/undo-tree.html>

[snip]

> IMvHO `undo-tree' should simply be made the default undo in Emacs.

In my experience, undo-tree is one of those packages that looks
impressive when you discover it but finally it is seldom used.

OTOH, some of us experienced catastrophic failures while using undo-tree
consisting on the disappearance of all undo information.

Re: Emacs undo behavior frustrating for new users.

[Joost Kremers]

On Mon, Oct 15 2018, Óscar Fuentes wrote:
> Joost Kremers <joostkremers@fastmail.fm> writes:
>
> [snip]
>> the form of the `undo-tree' package: 
>>
>> <https://elpa.gnu.org/packages/undo-tree.html>
>
> [snip]
>
>> IMvHO `undo-tree' should simply be made the default undo in 
>> Emacs.
>
> In my experience, undo-tree is one of those packages that looks
> impressive when you discover it but finally it is seldom used.

Hmm, it's my default undo system and I wouldn't say I use it only 
rarely. I use the tree visualiser at least a couple of times a 
week.

Honestly, though, I believe any imaginable undo/redo system that 
keeps *all* past states of the buffer accessible would basically 
be a variation of undo-tree. And from a user POV, undo-tree is 
quite straightforward and easy-to-use, IMHO. It certainly has some 
bells and whistles that look impressive but may not be very useful 
in practice, but that doesn't change its basic usefulness.

Grafting a redo on Emacs' current undo system may be possible as 
well, I can't say, but I can't really imagine what such a system 
would look like. That may just be my lack of imagination, of 
course.

> OTOH, some of us experienced catastrophic failures while using 
> undo-tree
> consisting on the disappearance of all undo information.

That's not good, obviously. I never experienced anything like 
that.


-- 
Joost Kremers
Life has its moments

Re: Emacs undo behavior frustrating for new users. (WAS: 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. ]]]

  > Simple: C-z for Undo, C-S-z and possibly C-y for Redo, in cua-mode,

C-z is an important Emacs command.  To change it would hurt anyone.

CUA mode is not the main interface for Emacs.  To add this feature
we need to have it work with the usual command set.

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

Re: Emacs undo behavior frustrating for new users. (WAS: 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 have nothing in principle against switching to an Undo/Redo system.
  > > But there is an obstacle: finding a key for the Redo command.

  > C-< ;; for Undo
  > C-> ;; for Redo

These are hard to type, since they require Shift.
And they do not exist on terminals.



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

Re: Emacs undo behavior frustrating for new users. (WAS: delete-selection-mode as default)

[Yuri Khan]

On Tue, Oct 16, 2018 at 1:44 PM Richard Stallman <rms@gnu.org> wrote:

>   > Simple: C-z for Undo, C-S-z and possibly C-y for Redo, in cua-mode,
>
> C-z is an important Emacs command.  To change it would hurt anyone.
>
> CUA mode is not the main interface for Emacs.  To add this feature
> we need to have it work with the usual command set.

The target audience for a linear undo/redo system is likely to use
cua-mode, and also likely to not need suspend-frame (because they work
in a GUI Emacs and already have a window manager key binding to
minimize the GUI window).

Re: Emacs undo behavior frustrating for new users.

[Stefan Monnier]

> Grafting a redo on Emacs' current undo system may be possible as well,
> I can't say, but I can't really imagine what such a system would look
> like. That may just be my lack of imagination, of course.

AFAIK Emacs's undo info includes all the data needed for undo-tree, so
undo-tree could work on top of Emacs's normal undo system.

Whether it's worth the effort to do that is another question.


        Stefan

Re: Emacs undo behavior frustrating for new users.

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

  > AFAIK Emacs's undo info includes all the data needed for undo-tree, so
  > undo-tree could work on top of Emacs's normal undo system.

Would someone like to implement this?

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

Re: Emacs undo behavior frustrating for new users. (WAS: 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. ]]]

  > The target audience for a linear undo/redo system is likely to use
  > cua-mode,

I don't think so.  It might be good for everyone, if the keys
are convenient to type.

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

Re: Emacs undo behavior frustrating for new users. (WAS: delete-selection-mode as default)

[Nathan Moreau]

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

From my experience with undo-tree, C-S-/ is a good binding.
It is easy to reach right after hitting undo (C-/). Direct access is a
little bit hard but you don't tend to press it directly that often.


Nathan

On Tue, 16 Oct 2018, 08:45 Richard Stallman, <rms@gnu.org> wrote:

> [[[ 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 have nothing in principle against switching to an Undo/Redo system.
>   > > But there is an obstacle: finding a key for the Redo command.
>
>   > C-< ;; for Undo
>   > C-> ;; for Redo
>
> These are hard to type, since they require Shift.
> And they do not exist on terminals.
>
>
>
> --
> Dr Richard Stallman
> President, Free Software Foundation (https://gnu.org, https://fsf.org)
> Internet Hall-of-Famer (https://internethalloffame.org)
>
>
>
>

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

Re: Emacs undo behavior frustrating for new users.

[Andreas Schwab]

On Okt 17 2018, Nathan Moreau <nathan.moreau@m4x.org> wrote:

> From my experience with undo-tree, C-S-/ is a good binding.

That's impossible to type.

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: Emacs undo behavior frustrating for new users.

[Garreau, Alexandre]

On 2018-10-17 at 12:09, Nathan Moreau wrote:
> From my experience with undo-tree, C-S-/ is a good binding.
> It is easy to reach right after hitting undo (C-/). Direct access is a
> little bit hard but you don't tend to press it directly that often.

Are you really meaning shift when saying S- (or maybe super? which is
usually not accessible to emacs unless you use it as a window manager
through exwm)? Then what is your keyboard layout?

In qwerty and dvorak: S-/ is ?, so C-S-/ is C-?, which is impossible to
type (it gives ? usually), while corresponding to DEL under a terminal.

In azerty: / is already accessed with shift.

In bépo: S-/ is 9, so C-S-/ is C-9 and is already bound to
`digit-argument'

Re: Emacs undo behavior frustrating for new users.

[Nathan Moreau]

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

I mean C-?, which in qwerty is control-shift-/.

On Wed, 17 Oct 2018, 14:00 Garreau, Alexandre, <galex-713@galex-713.eu>
wrote:

> On 2018-10-17 at 12:09, Nathan Moreau wrote:
> > From my experience with undo-tree, C-S-/ is a good binding.
> > It is easy to reach right after hitting undo (C-/). Direct access is a
> > little bit hard but you don't tend to press it directly that often.
>
> Are you really meaning shift when saying S- (or maybe super? which is
> usually not accessible to emacs unless you use it as a window manager
> through exwm)? Then what is your keyboard layout?
>
> In qwerty and dvorak: S-/ is ?, so C-S-/ is C-?, which is impossible to
> type (it gives ? usually), while corresponding to DEL under a terminal.
>
> In azerty: / is already accessed with shift.
>
> In bépo: S-/ is 9, so C-S-/ is C-9 and is already bound to
> `digit-argument'
>

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

Re: Emacs undo behavior frustrating for new users.

[Garreau, Alexandre]

Le 17/10/2018 à 16h05, Nathan Moreau a écrit :
> I mean C-?, which in qwerty is control-shift-/.

For some reason I ignore, it appears to be sometimes not possible to
type in GUI (though I barely understand why it’s even possible to type
at all), and it is systematically impossible to type in terminal.

Look: Both (kbd "DEL") and "\C-?" display as "^?"  (if it pass our mail
softwares: "\x7f"), and contain only ?\C-? (127), which is usually
backspace (or is it sometimes different, as (kbd "<backspace>") returns
[backspace], which seems different?).

I believe this is an historic oddity of old terminal and/or keyboard,
related to how they implemented stuff.

Re: Emacs undo behavior frustrating for new users.

[Yuri Khan]

On Wed, Oct 17, 2018 at 7:01 PM Garreau, Alexandre
<galex-713@galex-713.eu> wrote:

> In qwerty and dvorak: S-/ is ?, so C-S-/ is C-?, which is impossible to
> type (it gives ? usually), while corresponding to DEL under a terminal.

In the age of hardware terminals, it might have been reasonable that
the Control key only lets you enter the 33 control characters.

These days? Control and Alt are just modifier keys that can be pressed
with every other key, whether alphabetic, numeric, or functional.
Today’s terminal emulators should learn to pass these to applications
faithfully.

Somebody has even invented an encoding scheme to be able to represent
keys with modifiers:

https://sw.kovidgoyal.net/kitty/protocol-extensions.html#keyboard-handling

Re: Emacs undo behavior frustrating for new users.

[Eli Zaretskii]

> From: Yuri Khan <yurivkhan@gmail.com>
> Date: Wed, 17 Oct 2018 21:33:49 +0700
> Cc: van@scratch.space, nathan.moreau@m4x.org, rms@gnu.org,
> 	Emacs developers <emacs-devel@gnu.org>
> 
> These days? Control and Alt are just modifier keys that can be pressed
> with every other key, whether alphabetic, numeric, or functional.

But the results are non-portable when used with keys that produce
non-ASCII characters, so these combinations are better avoided.

Re: Emacs undo behavior frustrating for new users.

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

  > > From my experience with undo-tree, C-S-/ is a good binding.

  > That's impossible to type.

On a text console, it is literally impossible.

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

Re: Emacs undo behavior frustrating for new users.

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

  > Today’s terminal emulators should learn to pass these to applications
  > faithfully.

I agree that would be a step forward.  The one I use is, I think,
part of Linux.


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

Re: Emacs undo behavior frustrating for new users. (WAS: delete-selection-mode as default)

[Marcin Borkowski]

On 2018-10-16, at 08:44, Richard Stallman <rms@gnu.org> wrote:

> [[[ 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. ]]]
>
>   > Simple: C-z for Undo, C-S-z and possibly C-y for Redo, in cua-mode,
>
> C-z is an important Emacs command.  To change it would hurt anyone.

FWIW, I find the default binding of C-z totally useless and a waste of
a good keybinding.  I rebound it as a prefix key for my keymap
containing lots of useful commands.

So not anyone (though this change would hurt _me_, but for other
reasons).

Just one data point.

Best,

--
Marcin Borkowski
http://mbork.pl

Re: Emacs undo behavior frustrating for new users. (WAS: delete-selection-mode as default)

[Elias Mårtenson]

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

On Sat, 20 Oct 2018, 16:17 Marcin Borkowski, <mbork@mbork.pl> wrote:

>
> FWIW, I find the default binding of C-z totally useless and a waste of
> a good keybinding.  I rebound it as a prefix key for my keymap
> containing lots of useful commands.
>

Also FWIW, I also find the default not only useless, but annoying. I have
rebound it to scrolling down by one line (and M-z for scrolling down).
Those mappings come from the gosmacs bindings that used to be part of GNU
Emacs until they were removed.

Regards,
Elias

>

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