emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Gitlab Migration


From: Dmitry Gutov
Subject: Re: Gitlab Migration
Date: Fri, 10 Sep 2021 06:09:29 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0

On 09.09.2021 06:07, Richard Stallman 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. ]]]

   > Others replied later that users generally expect 'redo' to require one
   > more modifier than 'undo'. In graphical Emacs, it can work out to having
   > 'C-/' call 'undo', then one can additionally hold down the Shift key to
   > the right of '/', calling 'redo' with the resulting 'C-?'.

If users are happy with that, I won't argue against it.  It doesn't have
any other problem.

We still have the problem of ttys.  We can't use C-/ or C-? on a tty
because each of them is the same character as DEL.  So we use C-_ instead
for undo.

Because there is no difference on a tty between C-_ and C--.
there is no way to disguinuish between Sh-C-- and C--.

I previously suggested M-_ (working fine on my tty), but it does make the transition more awkward.

However, C-M-- could be used for redo on ttys.

Does that make everyone happy?  If so, maybe we're ready to
introduce that binding.

That's pretty elegant. On tty, the user would press C-- to undo and C-M-- to redo. One-modifier difference.

Though in my testing I had to bind C-M-_ instead. That's what my tty Emacs translated the combination to. And that also resolved the conflict with the existing 'C-M--' binding for 'negative-argument'.

Initially we should continue the current behavior of undo
to avoid an incompatible change, and have an option to enablke
the undo-redo behavior.  Once Emacs 28 is out, we could find out
what the users think and whether we old fogeys can adjust to undo-redo.
Then we could decide whether to make that the default.

Sounds good.

I wonder if we should add some mechanism to detect that the user had called undo-redo in the current session, and then one of his/her undo-s is going to perform a "redoing" undo (and suggest to disable the behavior, by changing some user option that will turn their 'undo' into 'undo-only').

Or maybe the attached patch is enough: long-time users will use 'undo' like they always did, and the undo-redo users aren't generally going to notice that 'undo' sometimes goes too far.

We should also modify cua-mode to use undo-redo, but that can go in after.

Attachment: undo-redo-bindings.diff
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]