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

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

[Bingo]

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

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

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

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

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

Thanks

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

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

[Eli Zaretskii]

> Date: Sat, 08 Sep 2018 09:19:21 +0530
> From: Bingo <right.ho@gmail.com>
> 
> Can we consider changing defaults only for users who don't have any init file at all ?
> 
> This change may not solve many problems, due to two other features of emacs : 

What problems will such a change solve?

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

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

> 1. Emacs undo is frustrating for most new users. Correcting mistakes with delete-selection-mode i.e. restore
> a selection that was deleted due to a mistaken delete by typing/pasting , will need them to use undo. 
> 
> 2. In their attempt to play with undo/redo, they might do C-y. Which pastes in Emacs : but it is the key for redo
> in many "modern" editors. This can cause more unintended deletions in delete-selection-mode.

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

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

[Bingo]

Le 8 septembre 2018 12:53:46 GMT+05:30, Eli Zaretskii <eliz@gnu.org> a écrit :
>> Date: Sat, 08 Sep 2018 09:19:21 +0530
>> From: Bingo <right.ho@gmail.com>
>> 
>> Can we consider changing defaults only for users who don't have any
>init file at all ?
>> 
>> This change may not solve many problems, due to two other features of
>emacs : 
>
>What problems will such a change solve?
>
>Personally, I think that changing the behavior just because there's an
>init file, even though that init file doesn't explicitly mention the
>affected features, would be confusing.
>
>More importantly, I think the argument about the defaults, at least
>for veteran Emacs users matters mainly when there is no init file
>anyway.

I mean :

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

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

3. If not, create an init file with these "modern" options. This can attract the new users we want. Modern software create a lot of files and registry entries for cache and config, no one would blame Emacs.

>
>> 1. Emacs undo is frustrating for most new users. Correcting mistakes
>with delete-selection-mode i.e. restore
>> a selection that was deleted due to a mistaken delete by
>typing/pasting , will need them to use undo. 
>> 
>> 2. In their attempt to play with undo/redo, they might do C-y. Which
>pastes in Emacs : but it is the key for redo
>> in many "modern" editors. This can cause more unintended deletions in
>delete-selection-mode.
>
>So I guess you are saying delete-selection-mode should not be turned
>on by default?  If so, why do we need the change you propose?

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


Thanks a lot

Hi Eli, clarified inline :

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

[Eli Zaretskii]

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

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

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

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

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

[Alan Mackenzie]

Hello, Eli.

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

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

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

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

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

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

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

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Drew Adams]

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

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

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

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

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

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

[Eli Zaretskii]

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

Yes, of course.  Same here.

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

[Ergus]

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

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

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

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

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

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

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

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

[Alan Mackenzie]

Hello, Ergus.

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

As a counterexample to your argument, look at the inconsistent series of
messes that recent versions of Firefox have become.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Ergus]

On Sun, Sep 09, 2018 at 07:12:53PM +0000, Alan Mackenzie wrote:

Hello Alan:
>Hello, Ergus.
>
>On Sun, Sep 09, 2018 at 19:59:53 +0200, Ergus wrote:
>
>> On Sun, Sep 09, 2018 at 01:13:16PM +0000, Alan Mackenzie wrote:
>> >Hello, Eli.
>
>> >On Sat, Sep 08, 2018 at 12:26:43 +0300, Eli Zaretskii wrote:
>> >> > Date: Sat, 08 Sep 2018 14:03:46 +0530
>> >> > CC: emacs-devel@gnu.org
>> >> > From: Bingo <right.ho@gmail.com>
>
>> >> > 1. When Emacs first starts, see if there is an init file. Various
>> >> > modern software do so, so we would be on solid ground there.
>
>> >> > 2. If so, trust the user that he would have set delete-selection-mode
>> >> > as required.
>
>> >> I'm not sure this is a valid assumption.  A user could have
>> >> delete-selection-mode not turned on because she had no idea such a
>> >> thing existed in Emacs.
>
>> >> >  This would avoid stepping on the toes of power users : which form
>> >> >  the majority of Emacs users.
>
>> >> Please note that veteran users only care about defaults when they need
>> >> to use Emacs on someone else's machine, or when logged on as some other
>> >> user (like root or su).
>
>> >A third situation, in which at least one veteran user (me) cares is when
>> >testing a bug fix with emacs -Q.  In such cases, I can get fairly
>> >irritated by, e.g., transient-mark-mode, and would get even more
>> >irritated were delete-selection-mode to be enabled by default.
>
>> >--
>> >Alan Mackenzie (Nuremberg, Germany).
>
>
>> I understand this. But then I only see 2 possible solutions:
>
>> 1) Keep emacs defaults only for experienced users, so forget about
>> getting new users and let it die slowly.
>
>Emacs is over 40 years old, and has seen many fads come and go.  It has
>been steadily acquiring new users in that time, and losing old ones.  As
>a program it combines extreme user friendliness with a long steep
>learning curve (i.e. it is not "beginner friendly").  I don't think we
>should be trying to change these attributes.
>
I partially agree because the project survived more or less
actively. But in the last 10 years the use have strongly declined.

The first 20 years emacs adapted to changes very quickly, changing
details, architectures, adopting gui, extending. After the 2000 appeared
many other editors and they more or less standardized what text editing
is. But also other factors affected the emacs extension like the
ubiquity of windows, notepad++ (with almost not learning curve), emacs
not being installed by default in the GNU/Linux distributions. So emacs
keeps a number of users like in the 90s while now the number of
programmers and developers in the world is orders of magnitude higher.
And we did nothing.

>> 2) Start thinking in the new generations who will inherit emacs but
>> already have a standard idea of how editors should behave; very
>> different of the emacs defaults.
>
>Many of them, faced with a choice between lots of clones which behave in
>a beginner-friendly, but suboptimal fashion, and the freshness of Emacs
>will come to chose Emacs.  We should not deprive them of this choice by
>dumbing down Emacs.
>
>Incidentally, the current discussion, in essence, has been going on on
>this list for the last 20 years or so, and probably quite a bit longer.
>
The point is that emacs can bring the same experience than any other
editor just some configuration (projects like spacemacs proves
this). But the default experience is too different that most users feel
scared and move to something "simpler". And we do nothing to avoid this;
stating with the tutorial or the online documentation (where 99% of the
users look for stuff and not in the self documentation, stackoverflow
success is the prove that nobody reads the manuals or the full
documentation in our days). 

There is not an interactive foro where users can make questions and
answer each other actively, and if the emacswiki is not updated in many
articles is a prove that we don't have enough users proportional to the
projects' dimension.  Add to this that many packages and functionalities
are duplicated in different packages and the user gets confused and some
packages in the repositories are unmaintained since 5 years or more.

Looking how the number of sublime text users grew in 2 years shows all
the users that emacs is loosing just for not bringing an initial good
face. Because Sublime is not superior to emacs in any sense, except the
behavior that is "like expected".

>> As a good consensus (and we are again where this thread started) is the
>> option to make an initial assistant (like the one in spacemacs but maybe
>> more complete) which can provide a bunch of options to the user to
>> set/unset them (with some information or more options depending of the
>> user (it can start with standard, advanced, minimal like many other
>> programs)). And add this configuration as the init file (if there was
>> not one) or as an extra file that cannot be skipped with -Q but with
>> another option that could be added.
>
>I suggested something similar some years ago, but never got around to
>implementing it: that there be several sets of defaults, and a user
>choses a set of defaults by the name of the command she starts Emacs
>with: for example, I would start emacs-classic, whereas you would start
>something like emacs-cua.  This could be implemented by hard links, with
>the Emacs binary finding its "pre-"initialisation file by checking the
>name it was invoked by.  Or something like that.
>
>> This is maybe a bit more complicated to implement, but it can satisfy
>> both cases somehow.
>
>> There is a point where old projects need to adapt themselves to the
>> running times, .....
>
>You have to be careful that this doesn't mean dumbing down.
>
OK, but it doesn't mean that everything should be frozen and unchanged
because it works as it is. Maybe is can be better, or in general the
users prefer that way (there should be a reason); and the project is not
only for it's developers.

Have you ever think why there are so many sublime text users?

>> .... not only importing functionalities, but also updating
>> functionalities they already have in order to improve them. But we need
>> to think in the normal users which are majority in any project.
>
>As a counterexample to your argument, look at the inconsistent series of
>messes that recent versions of Firefox have become.
>
Yes, But Firefox lost like the 70% of its users in 5 years because they
offered the same experience but the rest of the world moved on, so they
just tried to fix the issues they had with speed and memory usage. They
also have the chrome competition and they depend of web architectures
and interfaces that evolves constantly. So the comparison is not
parallel with emacs from my point of view.

But, as a consequence of latest changes, many chrome, chromium, and
Opera users moved back to Firefox again. Plugins started to be
maintained again, there are some more contributors now. If they had made
the changes gradually among the years maybe some users keep there but
also the changes had been not so drastic and the users had time to
adapt. In general the project has more live now, in spite of the
problems associated with any big change. And actually Firefox works
better now than before Quantum, specially in mobile.
>-- 
>Alan Mackenzie (Nuremberg, Germany).

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

[Drew Adams]

> But the default experience is too different that most users feel
> scared and move to something "simpler". And we do nothing to avoid this;
> stating with the tutorial or the online documentation (where 99% of the
> users look for stuff and not in the self documentation, stackoverflow
> success is the prove that nobody reads the manuals or the full
> documentation in our days).

It's true that many users, particularly younger ones, do not look
first (or much) to the documentation these days. This is true
generally, not just for Emacs. It seems quicker and easier to
google, watch a video, or ask a question on a Q&A site.

That's not a reason not to continue having great documentation,
IMO. And the fact that a new Emacs user won't necessarily think
of or learn about `C-h m' etc. is not a reason not to continue to
have great doc strings and help commands.

And often the ultimate result of googling or posing a question
here or there is to end up at an Emacs manual. IOW, there needs
to be some real meat-and-bones content somewhere. And for
Emacs the main repositories of such content are (1) the code
itself, (2) the Emacs manual, and (3) the Elisp manual. (And
other Emacs manuals, such as Org.)

On sites like emacs.stackexchange, while providing an answer
to a question I, and others, generally try to also teach how to
ask questions of Emacs itself, including the help commands
and how to use the manual efficiently.

Emacs is different from many interactive interfaces for
developers in being particularly helpful and discoverable.
There's room for improvement, of course.

But the fact that new Emacs users might not know that
such self-help exists represents an opportunity to make it
more apparent. It's not a reason to put less emphasis on
the help and doc.

> There is not an interactive foro where users can make questions and
> answer each other actively, 

There are several, I think, from discussion sites such as reddit
to Q&A sites such as emacs.stackexchange. There is no GNU
forum, I guess. But I'm not convinced there needs to be one.

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

[Richard Stallman]

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

  > 1. Emacs undo is frustrating for most new users.

If that is true, it is an important issue.
What evidence is there for that statement?
If so, do we know why it is so?

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

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.

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

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

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

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

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

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

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

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

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

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

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

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)

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

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