From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: A possible CUA-mode bug about `cua-prefix-override-inhibit-delay` and its workaround Date: Sat, 25 May 2024 12:37:25 +0300 Message-ID: <86o78uz0yy.fsf@gnu.org> References: Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17352"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Siyuan Chen , Kim F. Storm Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat May 25 11:38:29 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sAnr9-0004E9-Kh for ged-emacs-devel@m.gmane-mx.org; Sat, 25 May 2024 11:38:27 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sAnqJ-000734-0U; Sat, 25 May 2024 05:37:35 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sAnqH-00072n-Kf for emacs-devel@gnu.org; Sat, 25 May 2024 05:37:33 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sAnqC-000549-Dt; Sat, 25 May 2024 05:37:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=5JtjhAhKN3t/OOcW7cw+IpVLQfvZKldPbh8ShVTfai4=; b=mSB+RjZ4c6z6 J9clz5xuUFj/idvfXTTZA5eqK5KZQ0XV4arv4Wv/HG+GVqJbE6f/Xjg2ltGKev8dpNmdlsUVGblzH 7AQcaMdZqL8e/23xfuzefiVFyKjX+QxGT55tCsKtN/rNefFxtkkAX5ri9VIU0obOqaMkLCIHM1cqP /mbBCIJhu6c/uOzjhyoGacD5mAWFR1Q8X8/xoPM+1lHKubpqQ5oVaj/kL9UqSIWzyExNi4jzEXBN8 l4dTYIaawM5nHjsjcb80ccmpUWEBm3HQ5xZNGruaiMEY4wb6afThUfDfyUg7JDNc0Yqyk9Cpvih9m 4w7VGIpBN63P7M817Q9Xrw==; In-Reply-To: (message from Siyuan Chen on Wed, 22 May 2024 15:25:20 +0800) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:319554 Archived-At: > From: Siyuan Chen > 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