bug#46369: 28.0.50; Bind clone-buffer into the new C-x x keymap

[Dmitry Gutov]

On 07.02.2021 23:19, Lars Ingebrigtsen wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
>
> > On 07.02.2021 20:26, Sean Whitton wrote:
> > > I noticed that Lars has bound rename-uniquely to C-x x u.
> >
> > Aside: I think this binding is inconsistent with 'vc-revert' (which is
> > 'C-x v u').
> >
> > Possible alternatives:
> >
> > - Not binding rename-uniquely at all.
> >
> > - Moving its binding to 'C-x x R' (so that two very similar commands
> >    don't take up different keys). And possibly moving revert-buffer to
> >    'C-x x u'.
>
> "u" is somewhat mnemonic for VCs, since `vc-revert' "undos" what you've
> done, but in non-VC buffers, it's not really -- you're
> reloading/regenerating, not undoing.

Also undoing, though: when the buffer has some unsaved changes.

> And `revert-buffer' is `g' in special-mode-map, so keeping it g-ish in
> the global map makes more sense, in my opinion.

Right, that too. So I don't really so much have a problem with 
'revert-buffer' being on 'C-x x g' as with 'rename-uniquely' being on 
'C-x x u'.

But if 'revert-buffer' were to move to 'C-x x u', I wouldn't find it 
odd. Because 'revert-buffer' pretty much has two different jobs:

- There are file-visiting buffers, revert-buffer-function is never set, 
and revert-buffer reverts to contents saved to disk as well as 
re-initializes the modes. Up until now this function never had a binding.

- There are non-file-visiting buffers, revert-buffer-function must be 
set, and the command does whatever revert-buffer-function says. This is 
usually bound to 'g', though apparently not always.

If these were two different commands, I don't think much would have 
changed for the vast majority of our users.