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

[Dmitry Gutov <dgutov@yandex.ru>]

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.