RE: Changes for emacs 28

[Drew Adams]

> > The mode will substitute undo with undo-only. This small contradiction
> > will start a war here.
> 
> As long as we keep this on the menu and the tool bar, there will be no
> reason for a "war".
> 
> > >> Having undo with an undo-redo in the same "state" could be confusing as
> > >> the normal undo could do also redo IMO.
> > >
> > >If the user uses the menus or the tool bar, the confusion will be
> > >spared, right?
> > >
> > If the user expects undo-only behavior; then having our undo will be
> > confusing because not expecting undo becoming a redo at some point.
> 
> How can it be confusing that 2 different commands produce different
> results?  Why isn't it confusing today, when we already have these 2
> commands?
> 
> > IMO we should have one (undo) or the other (undo-only + undo-edor) but
> > not mix them by default.
> 
> Whether to mix them or not is up to the user.

I'm coming to this late, and I won't go back & forth
about it.  I have only one thing to say about this
as a general topic (not limited to undo/redo etc.).

1. The Emacs menu should, above all, serve to help
discoverability.  Discovering what's possible, and
discovering what the current, "normal" _Emacs_ key
sequences are that correspond to menu items.

Above all, it's about discovering what _Emacs_ has
to offer.

2. The menu can _also_ include actions that help you
do some things for which we don't bind keyboard keys
- e.g., File > Open File.  This can be particularly
helpful for new users, who might expect something
that corresponds to what they're used to.

#2 is an addition.  It's not (should not be) the
main purpose of Emacs menus.  Emacs menus are for
all levels of Emacs users, and their main purpose
is for discovering - including rediscovering (i.e.,
finding) useful Emacs commands.  The main purpose
is #1, not #2.
___

#2 could (and does already, to some extent) apply
to undo/redo behavior.

IMO, we should definitely _not_ bind undo/redo
behavior to keys by default.  We should want to
lead new users to the _Emacs_ undo behavior,
which is superior to what they're used to.

IMO, this means classic Emacs `undo', but it could
mean `undo-tree' or some new variant that keeps
the power of classic Emacs `undo'.  It doesn't
mean the undo/redo that, say, an MS Word user is
used to.

A user who uses undo/redo from the menu bar should
_not_ see associated key bindings, and thus just
stay with what s?he is already used to instead of
discovering the superior behavior Emacs offers.

A new user will soon enough (maybe not immediately
but soon enough) find out how to bind keys to
commands, and can then bind the existing `undo'
keys (or any others) to undo/redo behavior, if
desired.

I think it would be a mistake if we go down the
road of both (a) offering menu items to accommodate
what newbies might be used to and (b) bind those
commands to keys.

That works against discoverability of Emacs's own,
superior commands.

This is a sense in which I agree with Dmitry about
inconsistency, but my reasoning is different.

Yes, we can discuss and disagree about whether
classic Emacs `undo' is actually superior to the
simple undo/redo that newbies might be used to.

But that's really beside the point I'm making,
which is not particularly about undo.

When we _do_ have a superior behavior, which we
agree about (which might not be the case for undo),
and that is bound to a keyboard key sequence, then
if we also decide to provide a menu item for an
inferior command with behavior closer to what a
newbie might expect, we should, as a general rule,
NOT bind the latter to a keyboard key by default.