GNU bug report logs - #31042
Emacs 27. Inserting a character doesn't always "deactivate" the mark.

Previous Next

Full log

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

From: Alan Mackenzie <acm <at> muc.de>
To: bug-gnu-emacs <at> gnu.org
Subject: Emacs 27. Inserting a character doesn't always "deactivate" the mark.
Date: Tue, 3 Apr 2018 13:42:46 +0000

Hello, Emacs.

In master, evaluate the following definition:

    (defun no-deactivate-mark-bug (arg)
      (interactive "P")
      (transient-mark-mode 1)
      (set-mark (point))
      (forward-char)
      (let ((inhibit-modification-hooks arg))
        (insert "a"))
      (message "deactivate-mark is %s" deactivate-mark))

.  In a non-empty buffer, with point not at end of buffer, do

    M-x no-deactivate-mark-bug

.  The character "a" will have been inserted, the region will not be
"active", and the message in the message area will confirm that
deactivate-mark had been set to t.  This is as it should be.

Now do

    C-u M-x no-deactivate-mark-bug

.  This time, after the insertion of "a", the region WILL spuriously be
"active", and the message will indicate that deactivate-mark was still
nil.  This is a bug.

I found this bug whilst integrating the new combine-change-calls macro
into Emacs.

What triggers this bug is inhibit-modification-hooks being non-nil.

The place where the bug is is in prepare_to_modify_buffer_1 in
.../src/insdel.c.  The test there of inhibit_modification_hooks rudely
exits before setting deactivate-mark to t.  A patch which fixes this
(still not tidied up; it's left as simple as possible to read) is:


diff --git a/src/insdel.c b/src/insdel.c
index 173c243834..1f45ccd28a 100644
--- a/src/insdel.c
+++ b/src/insdel.c
@@ -1951,9 +1951,10 @@ prepare_to_modify_buffer_1 (ptrdiff_t start, ptrdiff_t end,
   else
     base_buffer = current_buffer;
 
-  if (inhibit_modification_hooks)
-    return;
-
+  /* if (inhibit_modification_hooks) */
+  /*   return; */
+  if (!inhibit_modification_hooks)
+    {
   if (!NILP (BVAR (base_buffer, file_truename))
       /* Make binding buffer-file-name to nil effective.  */
       && !NILP (BVAR (base_buffer, filename))
@@ -1973,6 +1974,7 @@ prepare_to_modify_buffer_1 (ptrdiff_t start, ptrdiff_t end,
       = call1 (Fsymbol_value (Qregion_extract_function), Qnil);
 
   signal_before_change (start, end, preserve_ptr);
+    }
   Fset (Qdeactivate_mark, Qt);
 }
 

On a related note, it appears that in the same function, the file
locking is done for the first change in a buffer.  This locking would
appear not to be done if that first change to the buffer happens when
inhibit-modification-hooks is non-nil.  I haven't tested this, but it
would appear to be part of the same bug.

-- 
Alan Mackenzie (Nuremberg, Germany).
 

Previous Next

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