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

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

[Sean Whitton]

[-- Attachment #1: Type: text/plain, Size: 310 bytes --]

Hello,

I noticed that Lars has bound rename-uniquely to C-x x u.

I find that clone-buffer is a useful companion command to
rename-uniquely so would like to request binding C-x x n to that (the
letter 'n' follows Info-mode binding it to M-n).

Patch attached in case that makes this easier.

-- 
Sean Whitton

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Bind-clone-buffer-to-C-x-x-n.patch --]
[-- Type: text/x-diff, Size: 1564 bytes --]

From 3a6b6815f287622c100fcfdcc5b369e961de7b88 Mon Sep 17 00:00:00 2001
From: Sean Whitton <spwhitton@spwhitton.name>
Date: Sun, 7 Feb 2021 11:24:29 -0700
Subject: [PATCH] Bind clone-buffer to C-x x n

* lisp/bindings.el (ctl-x-x-map): Bind clone-buffer.
* etc/NEWS: Document the change.
---
 etc/NEWS         | 5 +++--
 lisp/bindings.el | 1 +
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/etc/NEWS b/etc/NEWS
index f65e3cf672..d4b792531e 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -241,8 +241,9 @@ search buffer due to too many matches being highlighted.
 ** A new keymap for buffer actions has been added.
 The 'C-x x' keymap now holds keystrokes for various buffer-oriented
 commands.  The new keystrokes are 'C-x x g' ('revert-buffer'),
-'C-x x r' ('rename-buffer'), 'C-x x u' ('rename-uniquely'),
-'C-x x i' ('insert-buffer') and 'C-x x t' ('toggle-truncate-lines').
+'C-x x r' ('rename-buffer'), 'C-x x u' ('rename-uniquely'), 'C-x x n'
+('clone-buffer'), 'C-x x i' ('insert-buffer') and 'C-x x t'
+('toggle-truncate-lines').
 
 \f
 * Editing Changes in Emacs 28.1
diff --git a/lisp/bindings.el b/lisp/bindings.el
index 9462468b1b..2f4bab11cf 100644
--- a/lisp/bindings.el
+++ b/lisp/bindings.el
@@ -1418,6 +1418,7 @@ if `inhibit-field-text-motion' is non-nil."
     (define-key map "g" #'revert-buffer)
     (define-key map "r" #'rename-buffer)
     (define-key map "u" #'rename-uniquely)
+    (define-key map "n" #'clone-buffer)
     (define-key map "i" #'insert-buffer)
     (define-key map "t" #'toggle-truncate-lines)
     map)
-- 
2.29.2

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

[Dmitry Gutov]

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'.

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

[Drew Adams]

> I noticed that Lars has bound rename-uniquely to C-x x u.
> 
> I find that clone-buffer is a useful companion command to
> rename-uniquely so would like to request binding C-x x n to that (the
> letter 'n' follows Info-mode binding it to M-n).

Please refrain from binding keys by default to
prefix key `C-x x'.

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

[Lars Ingebrigtsen]

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.

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

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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.

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

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> 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.

Yes, that's true -- they're really quite different things...  but I'm
not sure I feel much enthusiasm for detangling that bit at this point.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Lars Ingebrigtsen]

Sean Whitton <spwhitton@spwhitton.name> writes:

> I find that clone-buffer is a useful companion command to
> rename-uniquely so would like to request binding C-x x n to that (the
> letter 'n' follows Info-mode binding it to M-n).
>
> Patch attached in case that makes this easier.

Makes sense; applied now.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Dmitry Gutov]

On 08.02.2021 08:26, Lars Ingebrigtsen wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> 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.
> 
> Yes, that's true -- they're really quite different things...  but I'm
> not sure I feel much enthusiasm for detangling that bit at this point.

FWIW, I'm not saying we should split them (the benefits are small), but 
that keeping revert-buffer on 'g' in special modes and yet on 'C-x x u' 
otherwise can make sense.