[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.
undo-redo-bindings.diff
Description: Text Data
- Re: Gitlab Migration, (continued)
- Re: Gitlab Migration, Yuri Khan, 2021/09/07
- Re: Gitlab Migration, tomas, 2021/09/07
- Re: Gitlab Migration, Arthur Miller, 2021/09/07
- Re: Gitlab Migration, Dmitry Gutov, 2021/09/07
- Re: Gitlab Migration, Arthur Miller, 2021/09/07
- Re: Gitlab Migration, Dmitry Gutov, 2021/09/07
- Re: Gitlab Migration, Arthur Miller, 2021/09/07
- Re: Gitlab Migration, Richard Stallman, 2021/09/08
- Re: Gitlab Migration,
Dmitry Gutov <=
- Re: Gitlab Migration, Richard Stallman, 2021/09/11
- Re: Gitlab Migration, Dmitry Gutov, 2021/09/11
Re: Gitlab Migration, Dmitry Gutov, 2021/09/03
Re: Gitlab Migration, Simon Pugnet, 2021/09/03