GNU bug report logs - #79176
[PATCH] ; * lisp/indent-aux.el: Remove read-only text property

Previous Next

To reply to this bug, email your comments to 79176 AT debbugs.gnu.org.
There is no need to reopen the bug first.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Tony Zorman <mail <at> tony-zorman.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] ; * lisp/indent-aux.el: Remove read-only text property
Date: Tue, 05 Aug 2025 13:23:04 +0200

[Message part 1 (text/plain, inline)]

Tags: patch

Hi,

when one uses `kill-ring-deindent-mode' and selects read-only text, the
mode can't actually deindent it, which causes a lot of `beep' noise and
prevents the user from killing the selected text (or from any other
action, really). This patch fixes this by removing that particular
property before the text is inserted into the temporary buffer.

Thanks,
Tony

[0001-lisp-indent-aux.el-Remove-read-only-text-property.patch (text/patch, attachment)]

[Message part 3 (text/plain, inline)]

-- 
Tony Zorman | https://tony-zorman.com

Message #8 received at 79176 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Tony Zorman <mail <at> tony-zorman.com>
Cc: 79176 <at> debbugs.gnu.org
Subject: Re: bug#79176: [PATCH] ;
 * lisp/indent-aux.el: Remove read-only text property
Date: Tue, 05 Aug 2025 17:49:24 +0300

> From: Tony Zorman <mail <at> tony-zorman.com>
> Date: Tue, 05 Aug 2025 13:23:04 +0200
> 
> when one uses `kill-ring-deindent-mode' and selects read-only text, the
> mode can't actually deindent it, which causes a lot of `beep' noise and
> prevents the user from killing the selected text (or from any other
> action, really). This patch fixes this by removing that particular
> property before the text is inserted into the temporary buffer.

Thanks, but isn't it better to bind inhibit-read-only non-nil around
the code which modifies the text instead?  By default
yank-excluded-properties includes read-only, but what if someone
changes the value not to include read-only? won't they expect to see
the read-only property when the text is yanked?

Message #11 received at 79176 <at> debbugs.gnu.org (full text, mbox):

From: Tony Zorman <mail <at> tony-zorman.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79176 <at> debbugs.gnu.org
Subject: Re: bug#79176: [PATCH] ; * lisp/indent-aux.el: Remove read-only
 text property
Date: Wed, 06 Aug 2025 08:12:58 +0200

[Message part 1 (text/plain, inline)]

On Tue, Aug 05 2025 17:49, Eli Zaretskii wrote:
>> From: Tony Zorman <mail <at> tony-zorman.com>
>> Date: Tue, 05 Aug 2025 13:23:04 +0200
>> 
>> when one uses `kill-ring-deindent-mode' and selects read-only text, the
>> mode can't actually deindent it, which causes a lot of `beep' noise and
>> prevents the user from killing the selected text (or from any other
>> action, really). This patch fixes this by removing that particular
>> property before the text is inserted into the temporary buffer.
>
> Thanks, but isn't it better to bind inhibit-read-only non-nil around
> the code which modifies the text instead?  By default
> yank-excluded-properties includes read-only, but what if someone
> changes the value not to include read-only? won't they expect to see
> the read-only property when the text is yanked?

Ah, I didn't know about yank-excluded-properties. You're right, in that
case perhaps it's better to use inhibit-read-only; I've updated the
patch accordingly.

[0001-lisp-indent-aux.el-Remove-read-only-text-property.patch (text/x-patch, inline)]

From e5aa85fd98113debe0e287a9ccbe03fd8cec1493 Mon Sep 17 00:00:00 2001
From: Tony Zorman <mail <at> tony-zorman.com>
Date: Tue, 5 Aug 2025 13:08:43 +0200
Subject: [PATCH] ; * lisp/indent-aux.el: Remove read-only text property

---
 lisp/indent-aux.el | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/lisp/indent-aux.el b/lisp/indent-aux.el
index eeb8f1ee6bb..4a05136ac1a 100644
--- a/lisp/indent-aux.el
+++ b/lisp/indent-aux.el
@@ -50,13 +50,14 @@ is yanked."
                   (delete-and-extract-region beg end)
                 (buffer-substring beg end))))
     (with-temp-buffer
-      ;; Indent/deindent the same as the major mode in the original
-      ;; buffer.
-      (setq indent-tabs-mode i-t-m)
-      (insert text)
-      (indent-rigidly (point-min) (point-max)
-                      (- indentation))
-      (buffer-string))))
+      (let ((inhibit-read-only t))
+        ;; Indent/deindent the same as the major mode in the original
+        ;; buffer.
+        (setq indent-tabs-mode i-t-m)
+        (insert text)
+        (indent-rigidly (point-min) (point-max)
+                        (- indentation))
+        (buffer-string)))))
 
 ;;;###autoload
 (define-minor-mode kill-ring-deindent-mode
-- 
2.50.1

[Message part 3 (text/plain, inline)]

-- 
Tony Zorman | https://tony-zorman.com

Message #16 received at 79176-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Tony Zorman <mail <at> tony-zorman.com>
Cc: 79176-done <at> debbugs.gnu.org
Subject: Re: bug#79176: [PATCH] ; * lisp/indent-aux.el: Remove read-only
 text property
Date: Thu, 07 Aug 2025 16:13:56 +0300

> From: Tony Zorman <mail <at> tony-zorman.com>
> Cc: 79176 <at> debbugs.gnu.org
> Date: Wed, 06 Aug 2025 08:12:58 +0200
> 
> > Thanks, but isn't it better to bind inhibit-read-only non-nil around
> > the code which modifies the text instead?  By default
> > yank-excluded-properties includes read-only, but what if someone
> > changes the value not to include read-only? won't they expect to see
> > the read-only property when the text is yanked?
> 
> Ah, I didn't know about yank-excluded-properties. You're right, in that
> case perhaps it's better to use inhibit-read-only; I've updated the
> patch accordingly.

Thanks, now installed on the master branch (after fixing the commit
log message, since it still talked about removing the property).

I'm therefore closing this bug.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.