A possible CUA-mode bug about `cua-prefix-override-inhibit-delay` and its workaround

A possible CUA-mode bug about `cua-prefix-override-inhibit-delay` and its workaround

[Siyuan Chen]

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

 Hi Emacs-devel team,

Currently, there seems to be a bug in CUA-mode, i.e. when `(setq
cua-prefix-override-inhibit-delay nil)`, cut and copy do not work.

From the `cua-prefix-override-inhibit-delay` docs

> If non-nil, time in seconds to delay before overriding prefix key. If
there is additional input within this time, the prefix key is used as a
normal prefix key.  So typing a key sequence quickly will inhibit
overriding the prefix key. As a special case, if the prefix key is repeated
within this time, the first prefix key is discarded, so typing a prefix key
twice in quick succession will also inhibit overriding the prefix key.
> If the value is nil, use a shifted prefix key to inhibit the override."

So I assume that

(1) CUA-mode allows user `(setq cua-prefix-override-inhibit-delay nil)`.

(2) When `(setq cua-prefix-override-inhibit-delay nil)`, CUA-mode should
disable the timer feature, and expect the user to use Shift instead, i.e.
the old prefix key `C-x` -> new prefix key `C-S-x`.

Unfortunately, it is not the case. `(setq cua-prefix-override-inhibit-delay
nil)` will cause a totally disabled CUA-mode feature, i.e. selecting a
region and pressing `C-x` never cuts the region. This obviously breaks the
docs behavior!

Noticed that in cua-base.el, the `cua--prefix-override-replay` pushes back
the key `^X` to `unread-command-events` via `(setq unread-command-events
(cons (cons 'no-record key) unread-command-events))`, but no one handles it
in `cua--xxxx-keymap`. Yeah, when `(setq cua-prefix-override-inhibit-delay
0.2)`, there will be a timeout version keymap to handle

```
(define-key cua--cua-keys-keymap [(control x) timeout] #'kill-region)
(define-key cua--cua-keys-keymap [(control c) timeout]
#'copy-region-as-kill)
```

but no 'no-record version when `(setq cua-prefix-override-inhibit-delay
nil)`.

The following provides a workaround.

It does `kill-region` and `copy-region-as-kill ` directly in
`cua--prefix-override-keymap` when ` cua-prefix-override-inhibit-delay` is
nil (or < 0).

```
(defun --sc-cua--prefix-override-ctl-x ()
  (interactive)
  (if (or (not (numberp cua-prefix-override-inhibit-delay))
          (<= cua-prefix-override-inhibit-delay 0))
      (call-interactively #'kill-region)
    (call-interactively #'cua--prefix-override-handler)))

(defun --sc-cua--prefix-override-ctl-c ()
  (interactive)
  (if (or (not (numberp cua-prefix-override-inhibit-delay))
          (<= cua-prefix-override-inhibit-delay 0))
      (call-interactively #'copy-region-as-kill)
    (call-interactively #'cua--prefix-override-handler)))

(defun --sc-cua--init-keymaps()
  (define-key cua--prefix-override-keymap [(control x)]
#'--sc-cua--prefix-override-ctl-x)
  (define-key cua--prefix-override-keymap [(control c)]
#'--sc-cua--prefix-override-ctl-c))

(advice-add 'cua--init-keymaps :after #'--sc-cua--init-keymaps)
```

It worked well on my end, so I'm sharing it here in case someone is
interested and hoping it can be merged upstream (The `sc` defun prefix is
just my naming space, so don't care about it) .

The 2nd question someone might ask: Why do we have to set `(setq
cua-prefix-override-inhibit-delay nil)` and use the Shift version as prefix
keys? Why not keep the default value `0.2`?

The reason is that `0.2` prevents users from quick copy/cut operations!  Let's
do a simple experiment:

1. Enable cua-mode and `(setq cua-prefix-override-inhibit-delay 1)`.

2. You have two buffers, called BufferA and BufferB.

3. Go to BufferA and suppose there are two words in it, `Hello` and `World`
in it.

4. Select the `Hello` and press Ctrl+C and wait 1 second.

5. Select the `World` and press Ctrl+X and quickly switch to BufferB (via
mouse click tab in tab-line).

6. In BufferB, press Ctrl+V.

The expected behavior is the "World" is pasted but Emacs pastes
`Hello`. Reducing
the `cua-prefix-override-inhibit-delay` value (e.g. `0.01`) can partially
rescue the problem, but not much if someone is operating very very
fast and makes
the problem hard to detect. That is why we have to set `(setq
cua-prefix-override-inhibit-delay nil)`!

A possible related issue from
https://lists.gnu.org/archive/html/help-gnu-emacs/2016-06/msg00468.html

The user said that

> The symptoms are that I select some text (using the shifted arrowkeys),
copy it with C-c, switch to another application (typically an input form in
web browser) and paste. At this point I realise that mycopy operation
failed, as I get a stale clipboard value pasted.

I guess the user's issue is related to this one.

Tested in GNU Emacs 28.2 on Windows (I believe the 29.3 has the same
problem because `cua-base.el` is not much different except two defalias).

Thanks.

Best regards,
Siyuan Chen

[-- Attachment #2: Type: text/html, Size: 12036 bytes --]

Re: A possible CUA-mode bug about `cua-prefix-override-inhibit-delay` and its workaround

[Siyuan Chen]

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

 The previous patch, the C-c and C-x, can not work comfortably with the CUA
global mark feature since kill-ring-save and kill-region are remapped.

Use the following patch instead

```
(defun --sc-cua--prefix-override-ctl-c ()
  (interactive)
  (if (or (not (numberp cua-prefix-override-inhibit-delay))
          (<= cua-prefix-override-inhibit-delay 0))
      (cond
       (cua--global-mark-active (cua-copy-to-global-mark))
       ;; TODO: Do we have to remap C-x, C-c, C-v rectangle cut, copy,
paste?
       ;; Seems unnecessary because cua-rect.el doesn't handle them as well.
       ;; E.g. `cua--copy-rectangle-as-kill' is never called at least <=
Emacs 29.3
       ;; (cua--rectangle (cua--copy-rectangle-as-kill))
       (t (copy-region-as-kill)))
    (cua--prefix-override-handler)))

(defun --sc-cua--prefix-override-ctl-x ()
  (interactive)
  (if (or (not (numberp cua-prefix-override-inhibit-delay))
          (<= cua-prefix-override-inhibit-delay 0))
      (cond
       (cua--global-mark-active (cua-cut-to-global-mark))
       (t (kill-region)))
    (cua--prefix-override-handler)))
```

 P.s. It appears there is no need for special handling of the CUA rectangle
feature, as the original code (cua-rect.el) does not address it either.

Best regards,
Siyuan Chen

On Wed, May 22, 2024 at 3:25 PM Siyuan Chen <chansey97@gmail.com> wrote:

> Hi Emacs-devel team,
>
> Currently, there seems to be a bug in CUA-mode, i.e. when `(setq
> cua-prefix-override-inhibit-delay nil)`, cut and copy do not work.
>
> From the `cua-prefix-override-inhibit-delay` docs
>
> > If non-nil, time in seconds to delay before overriding prefix key. If
> there is additional input within this time, the prefix key is used as a
> normal prefix key.  So typing a key sequence quickly will inhibit
> overriding the prefix key. As a special case, if the prefix key is repeated
> within this time, the first prefix key is discarded, so typing a prefix key
> twice in quick succession will also inhibit overriding the prefix key.
> > If the value is nil, use a shifted prefix key to inhibit the override."
>
> So I assume that
>
> (1) CUA-mode allows user `(setq cua-prefix-override-inhibit-delay nil)`.
>
> (2) When `(setq cua-prefix-override-inhibit-delay nil)`, CUA-mode should
> disable the timer feature, and expect the user to use Shift instead, i.e.
> the old prefix key `C-x` -> new prefix key `C-S-x`.
>
> Unfortunately, it is not the case. `(setq
> cua-prefix-override-inhibit-delay nil)` will cause a totally disabled
> CUA-mode feature, i.e. selecting a region and pressing `C-x` never cuts the
> region. This obviously breaks the docs behavior!
>
> Noticed that in cua-base.el, the `cua--prefix-override-replay` pushes back
> the key `^X` to `unread-command-events` via `(setq unread-command-events
> (cons (cons 'no-record key) unread-command-events))`, but no one handles it
> in `cua--xxxx-keymap`. Yeah, when `(setq cua-prefix-override-inhibit-delay
> 0.2)`, there will be a timeout version keymap to handle
>
> ```
> (define-key cua--cua-keys-keymap [(control x) timeout] #'kill-region)
> (define-key cua--cua-keys-keymap [(control c) timeout]
> #'copy-region-as-kill)
> ```
>
> but no 'no-record version when `(setq cua-prefix-override-inhibit-delay
> nil)`.
>
> The following provides a workaround.
>
> It does `kill-region` and `copy-region-as-kill ` directly in
> `cua--prefix-override-keymap` when ` cua-prefix-override-inhibit-delay` is
> nil (or < 0).
>
> ```
> (defun --sc-cua--prefix-override-ctl-x ()
>   (interactive)
>   (if (or (not (numberp cua-prefix-override-inhibit-delay))
>           (<= cua-prefix-override-inhibit-delay 0))
>       (call-interactively #'kill-region)
>     (call-interactively #'cua--prefix-override-handler)))
>
> (defun --sc-cua--prefix-override-ctl-c ()
>   (interactive)
>   (if (or (not (numberp cua-prefix-override-inhibit-delay))
>           (<= cua-prefix-override-inhibit-delay 0))
>       (call-interactively #'copy-region-as-kill)
>     (call-interactively #'cua--prefix-override-handler)))
>
> (defun --sc-cua--init-keymaps()
>   (define-key cua--prefix-override-keymap [(control x)]
> #'--sc-cua--prefix-override-ctl-x)
>   (define-key cua--prefix-override-keymap [(control c)]
> #'--sc-cua--prefix-override-ctl-c))
>
> (advice-add 'cua--init-keymaps :after #'--sc-cua--init-keymaps)
> ```
>
> It worked well on my end, so I'm sharing it here in case someone is
> interested and hoping it can be merged upstream (The `sc` defun prefix is
> just my naming space, so don't care about it) .
>
> The 2nd question someone might ask: Why do we have to set `(setq
> cua-prefix-override-inhibit-delay nil)` and use the Shift version as prefix
> keys? Why not keep the default value `0.2`?
>
> The reason is that `0.2` prevents users from quick copy/cut operations!  Let's
> do a simple experiment:
>
> 1. Enable cua-mode and `(setq cua-prefix-override-inhibit-delay 1)`.
>
> 2. You have two buffers, called BufferA and BufferB.
>
> 3. Go to BufferA and suppose there are two words in it, `Hello` and `World`
> in it.
>
> 4. Select the `Hello` and press Ctrl+C and wait 1 second.
>
> 5. Select the `World` and press Ctrl+X and quickly switch to BufferB (via
> mouse click tab in tab-line).
>
> 6. In BufferB, press Ctrl+V.
>
> The expected behavior is the "World" is pasted but Emacs pastes `Hello`. Reducing
> the `cua-prefix-override-inhibit-delay` value (e.g. `0.01`) can partially
> rescue the problem, but not much if someone is operating very very fast
> and makes the problem hard to detect. That is why we have to set `(setq
> cua-prefix-override-inhibit-delay nil)`!
>
> A possible related issue from
> https://lists.gnu.org/archive/html/help-gnu-emacs/2016-06/msg00468.html
>
> The user said that
>
> > The symptoms are that I select some text (using the shifted arrowkeys),
> copy it with C-c, switch to another application (typically an input form in
> web browser) and paste. At this point I realise that mycopy operation
> failed, as I get a stale clipboard value pasted.
>
> I guess the user's issue is related to this one.
>
> Tested in GNU Emacs 28.2 on Windows (I believe the 29.3 has the same
> problem because `cua-base.el` is not much different except two defalias).
>
> Thanks.
>
> Best regards,
> Siyuan Chen
>

[-- Attachment #2: Type: text/html, Size: 10370 bytes --]

Re: A possible CUA-mode bug about `cua-prefix-override-inhibit-delay` and its workaround

[Stefan Kangas]

Siyuan Chen <chansey97@gmail.com> writes:

> Use the following patch instead

Thanks, but please send this patch to the bug-gnu-emacs list instead so
that we don't lose track of it.

It would be best if you could send your patch as an attachment, as the
result of running the command `git format-patch -1`.

Re: A possible CUA-mode bug about `cua-prefix-override-inhibit-delay` and its workaround

[Siyuan Chen]

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

Dear Eli,

> I think this is a documentation issue.
>
> When cua-prefix-override-inhibit-delay is nil, the prefix is never
> overridden, i.e. "C-x" will never delete the marked text.

The real problem is that if we have to set
`cua-prefix-override-inhibit-delay` non-nil, or setting
`cua-prefix-override-inhibit-delay` nil means "C-x" never delete the marked
text, then the CUA-mode will not be able to support fast copy/cut & paste
as I said in the original post.

> I added Kim to the discussion, in the hope that he could shed some
light on the intended behavior.

That's great.

Dear Stefan,

> but please send this patch to the bug-gnu-emacs list instead so
that we don't lose track of it.

OK. I will send it later.


On Sun, May 26, 2024 at 1:35 AM Stefan Kangas <stefankangas@gmail.com>
wrote:

> Siyuan Chen <chansey97@gmail.com> writes:
>
> > Use the following patch instead
>
> Thanks, but please send this patch to the bug-gnu-emacs list instead so
> that we don't lose track of it.
>
> It would be best if you could send your patch as an attachment, as the
> result of running the command `git format-patch -1`.
>

[-- Attachment #2: Type: text/html, Size: 1825 bytes --]

Re: A possible CUA-mode bug about `cua-prefix-override-inhibit-delay` and its workaround

[Siyuan Chen]

[-- Attachment #1.1: Type: text/plain, Size: 2408 bytes --]

 > but please send this patch to the bug-gnu-emacs list instead so
> that we don't lose track of it.

I have sent the patch to bug-gnu-emacs@gnu.org but I can't receive any
response which should be something like bug#xxx. I have subscribed to
bug-gnu-emacs and can receive other people's bug mail.

To make tracking easier (e.g. other people may use archive to search in the
future), I repeated the email title: "[PATCH] Fix C-x C-c do not work in
CUA-mode when cua-prefix-override-handler is ni" and added the patch
attachment here. This patch
(0001-Fix-the-issue-when-cua-prefix-override-handler-is-ni.patch) works in
Emacs 29.3.

Note that the patch I provided previously on May 24, 2024 only works in
Emacs 28.2 (newer cua-base.el has some changes). Also, there is a typo in
the previous patch that I forgot to call `call-interactively` to `
kill-region` and `copy-region-as-kill`.

So if someone uses Emacs 29.3 or newer build, please use this patch I just
attached or the patch I sent to bug-gnu-emacs in which the typo has been
also fixed.

Best regards,
Siyuan Chen

On Mon, May 27, 2024 at 6:20 PM Siyuan Chen <chansey97@gmail.com> wrote:

> Dear Eli,
>
> > I think this is a documentation issue.
> >
> > When cua-prefix-override-inhibit-delay is nil, the prefix is never
> > overridden, i.e. "C-x" will never delete the marked text.
>
> The real problem is that if we have to set
> `cua-prefix-override-inhibit-delay` non-nil, or setting
> `cua-prefix-override-inhibit-delay` nil means "C-x" never delete the marked
> text, then the CUA-mode will not be able to support fast copy/cut & paste
> as I said in the original post.
>
> > I added Kim to the discussion, in the hope that he could shed some
> light on the intended behavior.
>
> That's great.
>
> Dear Stefan,
>
> > but please send this patch to the bug-gnu-emacs list instead so
> that we don't lose track of it.
>
> OK. I will send it later.
>
>
> On Sun, May 26, 2024 at 1:35 AM Stefan Kangas <stefankangas@gmail.com>
> wrote:
>
>> Siyuan Chen <chansey97@gmail.com> writes:
>>
>> > Use the following patch instead
>>
>> Thanks, but please send this patch to the bug-gnu-emacs list instead so
>> that we don't lose track of it.
>>
>> It would be best if you could send your patch as an attachment, as the
>> result of running the command `git format-patch -1`.
>>
>

[-- Attachment #1.2: Type: text/html, Size: 4903 bytes --]

[-- Attachment #2: 0001-Fix-the-issue-when-cua-prefix-override-handler-is-ni.patch --]
[-- Type: text/plain, Size: 2046 bytes --]

From 006de6c527c02566185ca4f0e5f5e41175882d68 Mon Sep 17 00:00:00 2001
From: Siyuan Chen <chansey97@gmail.com>
Date: Tue, 28 May 2024 00:29:50 +0800
Subject: [PATCH] Fix the issue when cua--prefix-override-handler is nil C-x
 C-c doesn't work.

Detail see https://lists.gnu.org/archive/html/emacs-devel/2024-05/msg01033.html
---
 lisp/emulation/cua-base.el | 25 +++++++++++++++++++++----
 1 file changed, 21 insertions(+), 4 deletions(-)

diff --git a/lisp/emulation/cua-base.el b/lisp/emulation/cua-base.el
index fb6a8515d9e..cacd348c315 100644
--- a/lisp/emulation/cua-base.el
+++ b/lisp/emulation/cua-base.el
@@ -699,10 +699,27 @@ Repeating prefix key when region is active works as a single prefix key."
   (interactive)
   (cua--prefix-override-replay 0))
 
-;; These aliases are so that we can look up the commands and find the
-;; correct keys when generating menus.
-(defalias 'cua-cut-handler #'cua--prefix-override-handler)
-(defalias 'cua-copy-handler #'cua--prefix-override-handler)
+;; These two functions are so that we can look up the commands and find the
+;; correct keys when generating menus. Also, when cua--prefix-override-handler
+;; is nil, allow C-x C-c to cut/copy immediately without waiting for
+;; cua--prefix-override-timer to expire.
+(defun cua-cut-handler ()
+  (interactive)
+  (if (or (not (numberp cua-prefix-override-inhibit-delay))
+          (<= cua-prefix-override-inhibit-delay 0))
+      (cond
+       (cua--global-mark-active (cua-cut-to-global-mark))
+       (t (call-interactively 'kill-region)))
+    (cua--prefix-override-handler)))
+
+(defun cua-copy-handler ()
+  (interactive)
+  (if (or (not (numberp cua-prefix-override-inhibit-delay))
+          (<= cua-prefix-override-inhibit-delay 0))
+      (cond
+       (cua--global-mark-active (cua-copy-to-global-mark))
+       (t (call-interactively 'copy-region-as-kill)))
+    (cua--prefix-override-handler)))
 
 (defun cua--prefix-repeat-handler ()
   "Repeating prefix key when region is active works as a single prefix key."
-- 
2.32.0.windows.2

Re: A possible CUA-mode bug about `cua-prefix-override-inhibit-delay` and its workaround

[Siyuan Chen]

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

OK. I have received the mail bug#71230.

On Tue, May 28, 2024 at 1:33 AM Siyuan Chen <chansey97@gmail.com> wrote:

> > but please send this patch to the bug-gnu-emacs list instead so
> > that we don't lose track of it.
>
> I have sent the patch to bug-gnu-emacs@gnu.org but I can't receive any
> response which should be something like bug#xxx. I have subscribed to
> bug-gnu-emacs and can receive other people's bug mail.
>
> To make tracking easier (e.g. other people may use archive to search in
> the future), I repeated the email title: "[PATCH] Fix C-x C-c do not work
> in CUA-mode when cua-prefix-override-handler is ni" and added the patch
> attachment here. This patch
> (0001-Fix-the-issue-when-cua-prefix-override-handler-is-ni.patch) works in
> Emacs 29.3.
>
> Note that the patch I provided previously on May 24, 2024 only works in
> Emacs 28.2 (newer cua-base.el has some changes). Also, there is a typo in
> the previous patch that I forgot to call `call-interactively` to `
> kill-region` and `copy-region-as-kill`.
>
> So if someone uses Emacs 29.3 or newer build, please use this patch I
> just attached or the patch I sent to bug-gnu-emacs in which the typo has
> been also fixed.
>
> Best regards,
> Siyuan Chen
>
> On Mon, May 27, 2024 at 6:20 PM Siyuan Chen <chansey97@gmail.com> wrote:
>
>> Dear Eli,
>>
>> > I think this is a documentation issue.
>> >
>> > When cua-prefix-override-inhibit-delay is nil, the prefix is never
>> > overridden, i.e. "C-x" will never delete the marked text.
>>
>> The real problem is that if we have to set
>> `cua-prefix-override-inhibit-delay` non-nil, or setting
>> `cua-prefix-override-inhibit-delay` nil means "C-x" never delete the marked
>> text, then the CUA-mode will not be able to support fast copy/cut & paste
>> as I said in the original post.
>>
>> > I added Kim to the discussion, in the hope that he could shed some
>> light on the intended behavior.
>>
>> That's great.
>>
>> Dear Stefan,
>>
>> > but please send this patch to the bug-gnu-emacs list instead so
>> that we don't lose track of it.
>>
>> OK. I will send it later.
>>
>>
>> On Sun, May 26, 2024 at 1:35 AM Stefan Kangas <stefankangas@gmail.com>
>> wrote:
>>
>>> Siyuan Chen <chansey97@gmail.com> writes:
>>>
>>> > Use the following patch instead
>>>
>>> Thanks, but please send this patch to the bug-gnu-emacs list instead so
>>> that we don't lose track of it.
>>>
>>> It would be best if you could send your patch as an attachment, as the
>>> result of running the command `git format-patch -1`.
>>>
>>

[-- Attachment #2: Type: text/html, Size: 4665 bytes --]

Re: A possible CUA-mode bug about `cua-prefix-override-inhibit-delay` and its workaround

[Eli Zaretskii]

> From: Siyuan Chen <chansey97@gmail.com>
> Date: Wed, 22 May 2024 15:25:20 +0800
> 
> From the `cua-prefix-override-inhibit-delay` docs
> 
> > If non-nil, time in seconds to delay before overriding prefix key. If there is additional input within this time, the
> prefix key is used as a normal prefix key.  So typing a key sequence quickly will inhibit overriding the prefix
> key. As a special case, if the prefix key is repeated within this time, the first prefix key is discarded, so typing a
> prefix key twice in quick succession will also inhibit overriding the prefix key.
> > If the value is nil, use a shifted prefix key to inhibit the override."
> 
> So I assume that 
> 
> (1) CUA-mode allows user `(setq cua-prefix-override-inhibit-delay nil)`.
> 
> (2) When `(setq cua-prefix-override-inhibit-delay nil)`, CUA-mode should disable the timer feature, and expect
> the user to use Shift instead, i.e. the old prefix key `C-x` -> new prefix key `C-S-x`.

I think this is a documentation issue.  The behavior I see is as
follows:

  . If cua-prefix-override-inhibit-delay is a number, the user has
    that many seconds to type a command using the prefix without the
    prefix being overridden by CUA.  For example, with the default
    value of 0.2, typing "C-x C-f" within less than 0.2 sec with
    prompt with "Find file", but if you type "C-x" and wait longer,
    the marked text will be deleted instead, per what C-x does in CUA.
  . Alternatively, you can type "C-S-x", in which case the prefix is
    inhibited indefinitely, so typing "C-S-x C-f" invokes find-file
    even if you wait for a long time before typing "C-f".
  . When cua-prefix-override-inhibit-delay is nil, the prefix is never
    overridden, i.e. "C-x" will never delete the marked text.

I see the same behavior as far away in the past as Emacs 22.

I added Kim to the discussion, in the hope that he could shed some
light on the intended behavior.

> Unfortunately, it is not the case. `(setq cua-prefix-override-inhibit-delay nil)` will cause a totally disabled
> CUA-mode feature, i.e. selecting a region and pressing `C-x` never cuts the region. This obviously breaks the
> docs behavior!
> 
> Noticed that in cua-base.el, the `cua--prefix-override-replay` pushes back the key `^X` to
> `unread-command-events` via `(setq unread-command-events (cons (cons 'no-record key)
> unread-command-events))`, but no one handles it in `cua--xxxx-keymap`. Yeah, when `(setq
> cua-prefix-override-inhibit-delay 0.2)`, there will be a timeout version keymap to handle 
> 
> ```
> (define-key cua--cua-keys-keymap [(control x) timeout] #'kill-region)
> (define-key cua--cua-keys-keymap [(control c) timeout] #'copy-region-as-kill)
> ```
> 
> but no 'no-record version when `(setq cua-prefix-override-inhibit-delay nil)`. 
> 
> The following provides a workaround. 
> 
> It does `kill-region` and `copy-region-as-kill ` directly in `cua--prefix-override-keymap` when `
> cua-prefix-override-inhibit-delay` is nil (or < 0).
> 
> ```
> (defun --sc-cua--prefix-override-ctl-x ()
>   (interactive)
>   (if (or (not (numberp cua-prefix-override-inhibit-delay))
>           (<= cua-prefix-override-inhibit-delay 0))
>       (call-interactively #'kill-region)
>     (call-interactively #'cua--prefix-override-handler)))
> 
> (defun --sc-cua--prefix-override-ctl-c ()
>   (interactive)
>   (if (or (not (numberp cua-prefix-override-inhibit-delay))
>           (<= cua-prefix-override-inhibit-delay 0))
>       (call-interactively #'copy-region-as-kill)
>     (call-interactively #'cua--prefix-override-handler)))
> 
> (defun --sc-cua--init-keymaps()
>   (define-key cua--prefix-override-keymap [(control x)] #'--sc-cua--prefix-override-ctl-x)
>   (define-key cua--prefix-override-keymap [(control c)] #'--sc-cua--prefix-override-ctl-c))
> 
> (advice-add 'cua--init-keymaps :after #'--sc-cua--init-keymaps)
> ```
> 
> It worked well on my end, so I'm sharing it here in case someone is interested and hoping it can be merged
> upstream (The `sc` defun prefix is just my naming space, so don't care about it) .
> 
> The 2nd question someone might ask: Why do we have to set `(setq cua-prefix-override-inhibit-delay nil)` and
> use the Shift version as prefix keys? Why not keep the default value `0.2`?
> 
> The reason is that `0.2` prevents users from quick copy/cut operations! Let's do a simple experiment:
> 
> 1. Enable cua-mode and `(setq cua-prefix-override-inhibit-delay 1)`.
> 
> 2. You have two buffers, called BufferA and BufferB.
> 
> 3. Go to BufferA and suppose there are two words in it, `Hello` and `World` in it.
> 
> 4. Select the `Hello` and press Ctrl+C and wait 1 second.
> 
> 5. Select the `World` and press Ctrl+X and quickly switch to BufferB (via mouse click tab in tab-line).
> 
> 6. In BufferB, press Ctrl+V.
> 
> The expected behavior is the "World" is pasted but Emacs pastes `Hello`. Reducing the
> `cua-prefix-override-inhibit-delay` value (e.g. `0.01`) can partially rescue the problem, but not much if
> someone is operating very very fast and makes the problem hard to detect. That is why we have to set `(setq
> cua-prefix-override-inhibit-delay nil)`!
> 
> A possible related issue from https://lists.gnu.org/archive/html/help-gnu-emacs/2016-06/msg00468.html 
> 
> The user said that
> 
> > The symptoms are that I select some text (using the shifted arrowkeys), copy it with C-c, switch to another
> application (typically an input form in web browser) and paste. At this point I realise that mycopy operation
> failed, as I get a stale clipboard value pasted.
> 
> I guess the user's issue is related to this one.
> 
> Tested in GNU Emacs 28.2 on Windows (I believe the 29.3 has the same problem because `cua-base.el` is
> not much different except two defalias).
> 
> Thanks.
> 
> Best regards,
> Siyuan Chen