[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#31042: Emacs 27. Inserting a character doesn't always "deactivate" t
bug#31042: Emacs 27. Inserting a character doesn't always "deactivate" the mark.
Tue, 3 Apr 2018 13:42:46 +0000
In master, evaluate the following definition:
(defun no-deactivate-mark-bug (arg)
(let ((inhibit-modification-hooks arg))
(message "deactivate-mark is %s" deactivate-mark))
. In a non-empty buffer, with point not at end of buffer, do
. 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.
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
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
@@ -1951,9 +1951,10 @@ prepare_to_modify_buffer_1 (ptrdiff_t start, ptrdiff_t
base_buffer = current_buffer;
- if (inhibit_modification_hooks)
+ /* 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
= 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).
- bug#31042: Emacs 27. Inserting a character doesn't always "deactivate" the mark.,
Alan Mackenzie <=