bug#46836: 28.0.50; Clean up obsolete comment for unchain_marker

bug#46836: 28.0.50; Clean up obsolete comment for unchain_marker

[Matt Armstrong]

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

I wondered why there was a scare comment for unchain_marker, when the
code itself did not look like it was especially different from the other
nearby functions.  It turns out that the call into this function from GC
was removed a few years ago.


[-- Attachment #2: 0001-Clean-up-obsolete-comment.patch --]
[-- Type: text/x-patch, Size: 1580 bytes --]

From c03f9fc86ee79a995acae012cac07609ebaa3d5e Mon Sep 17 00:00:00 2001
From: Matt Armstrong <matt@rfc20.org>
Date: Sun, 28 Feb 2021 14:41:33 -0800
Subject: [PATCH] Clean up obsolete comment
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Commit cf3164523b (* src/alloc.c: Avoid O(N²) complexity when
unchaining markers (bug#24548)., 2018-03-23) removed the call from GC
into unchain_marker, so there is no need to warn about it.

* src/marker.c (unchain_marker): Clean up obsolete comment.
---
 src/marker.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/src/marker.c b/src/marker.c
index 5979151317..2b137b14c8 100644
--- a/src/marker.c
+++ b/src/marker.c
@@ -634,16 +634,15 @@ set_marker_restricted_both (Lisp_Object marker, Lisp_Object buffer,
 /* Detach a marker so that it no longer points anywhere and no longer
    slows down editing.  Do not free the marker, though, as a change
    function could have inserted it into an undo list (Bug#30931).  */
+
 void
 detach_marker (Lisp_Object marker)
 {
   Fset_marker (marker, Qnil, Qnil);
 }
 
-/* Remove MARKER from the chain of whatever buffer it is in,
-   leaving it points to nowhere.  This is called during garbage
-   collection, so we must be careful to ignore and preserve
-   mark bits, including those in chain fields of markers.  */
+/* Remove MARKER from the chain of whatever buffer it is in.  Set its
+   buffer NULL.  */
 
 void
 unchain_marker (register struct Lisp_Marker *marker)
-- 
2.30.0


[-- Attachment #3: Type: text/plain, Size: 329 bytes --]



In GNU Emacs 28.0.50 (build 1, x86_64-apple-darwin20.3.0, NS appkit-2022.30 Version 11.2.1 (Build 20D74))
 of 2021-02-27 built on matts-mbp-2016.lan
Repository revision: de33de1a660283f45a10acfaedef20c460553dbd
Repository branch: master
Windowing system distributor 'Apple', version 10.3.2022
System Description:  macOS 11.2.2

bug#46836: 28.0.50; Clean up obsolete comment for unchain_marker

[Lars Ingebrigtsen]

Matt Armstrong <matt@rfc20.org> writes:

> I wondered why there was a scare comment for unchain_marker, when the
> code itself did not look like it was especially different from the other
> nearby functions.  It turns out that the call into this function from GC
> was removed a few years ago.

[...]

> -/* Remove MARKER from the chain of whatever buffer it is in,
> -   leaving it points to nowhere.  This is called during garbage
> -   collection, so we must be careful to ignore and preserve
> -   mark bits, including those in chain fields of markers.  */
> +/* Remove MARKER from the chain of whatever buffer it is in.  Set its
> +   buffer NULL.  */

Thanks; applied to Emacs 28.

Looking at the code in unchain_marker, I was a bit confused, because the
code looks very straightforward?  I wondered whether the function could
also be simplified now that it doesn't have to preserve mark bits...

But all the special mark bit code was removed from this code a couple
decades ago.  :-)

commit 5e097e002ba08205c8a4643b3495dbd45462147f
Author:     Stefan Monnier <monnier@iro.umontreal.ca>
AuthorDate: Thu Jun 26 23:17:50 2003 +0000

...

 	  else
-	    {
-	      omark = XMARKBIT (XMARKER (prev)->chain);
-	      XMARKER (prev)->chain = next;
-	      XSETMARKBIT (XMARKER (prev)->chain, omark);
-	    }


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no