Re: Gitlab Migration

[Dmitry Gutov]

On 12.09.2021 04:47, 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. ]]]
>
>    > C-M-- to redo. One-modifier difference.
>
>    > Though in my testing I had to bind C-M-_ instead.
>
> That's right.  You can type C-M--, but it really turns into C-M-_.
> Same for C--; it really turns into C-_.

Yep.

>    > 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
>
> You're trying to solve a problem, but I'm not sure precisely what.  I
> think we've made different assumptions and thus are miscommunicating.

The plan, as I understood it, was to introduce bindings for the new 
command: undo-redo. But to keep the old binding for 'undo'. Which the 
previous sent patch does.

That can create a problem for users new to Emacs (but with experience 
with some other editors) that, since 'undo' is still not the kind of 
'undo' they are used to, so invoking, for example, 'undo undo right left 
undo', might have a certain unexpected effect. So we could use a 
mechanism to correct it automatically, or suggest to the user how to 
correct it, without them having to read the docs.

That said, the problem of unfamiliar undo isn't new, and certain 
conditions would now need to be met for the user to encounter it (as 
opposed to all previous releases of Emacs, where the lack of 'redo' 
command made the said problem much bigger).

> My idea was to have two options, undo-only and undo-redo, with a way
> for the user to select one.  Initially the default would continue to
> be undo-only.  We would ask users try undo-redo; if they generally
> like it, we could change the default later to undo-redo.

The phrasing of this proposal reads a bit off since the command 
'undo-only' exists, and it does the opposite of what you imagined 
'undo-only' would mean: it it a version of 'undo' which won't redo any 
of the previous 'undo' actions. So it's basically meant to be used 
together with 'undo-redo'.

To restate your proposal how I understood it: we will add a binding for 
'undo-redo', and we will have a user option which will change how 'undo' 
works: either it works as it always did (the default), or it will not 
undo redos. The latter is meant to be used together with 'undo-redo'.

Such variable already exists: undo-no-redo. We can simply turn it into a 
defcustom and document more prominently.

> It looks like you're presuming something different (though I am not
> sure what it is) and proposing a DWIM feature for it, but I can't tell.
> Would you please spell out both what behavior you're presuming, and
> what behavior you propose instead?
I was thinking we would detect that the user had called undo-redo in the 
current session. If they had, and if one of their 'undo' invocations is 
about to "undo a redo", we would suggest to the user, just once, that 
they customize 'undo-no-redo' to t, to prevent this kind of thing from 
happening.

That's the best I could come up with; other suggestions are welcome, of 
course. Or, again, we can choose not to try to solve this now.