summaryrefslogtreecommitdiff
path: root/src/buffer.c
diff options
context:
space:
mode:
authorStefan Monnier <monnier@iro.umontreal.ca>2018-10-14 16:44:21 -0400
committerStefan Monnier <monnier@iro.umontreal.ca>2018-10-14 16:44:21 -0400
commit8c68e4afa8eebb6f738fdce600a6815509ac50a3 (patch)
tree36bfa55ae5bcf1f36a7c5754ca1a4729cace4c1d /src/buffer.c
parentf1ea2b9e6b63593f5919f60a68a9e19026756ac4 (diff)
downloademacs-8c68e4afa8eebb6f738fdce600a6815509ac50a3.tar.gz
emacs-8c68e4afa8eebb6f738fdce600a6815509ac50a3.tar.bz2
emacs-8c68e4afa8eebb6f738fdce600a6815509ac50a3.zip
* src/buffer.c (Fmove_overlay): Don't call Fdelete_overlay
... because the data structure is not in a consistent state. * test/src/buffer-tests.el (overlay-evaporation-after-killed-buffer): New test.
Diffstat (limited to 'src/buffer.c')
-rw-r--r--src/buffer.c22
1 files changed, 21 insertions, 1 deletions
diff --git a/src/buffer.c b/src/buffer.c
index 024e64f0d74..ac2de7d19f2 100644
--- a/src/buffer.c
+++ b/src/buffer.c
@@ -3991,6 +3991,16 @@ buffer. */)
unchain_both (ob, overlay);
}
+ else
+ /* An overlay not associated with any buffer will normally have its
+ `next' field set to NULL, but not always: when killing a buffer,
+ we just set its overlays_after and overlays_before to NULL without
+ manually setting each overlay's `next' field to NULL.
+ Let's correct it here, to simplify subsequent assertions.
+ FIXME: Maybe the better fix is to change `kill-buffer'!? */
+ XOVERLAY (overlay)->next = NULL;
+
+ eassert (XOVERLAY (overlay)->next == NULL);
/* Set the overlay boundaries, which may clip them. */
Fset_marker (OVERLAY_START (overlay), beg, buffer);
@@ -4020,10 +4030,20 @@ buffer. */)
modify_overlay (b, min (o_beg, n_beg), max (o_end, n_end));
}
+ eassert (XOVERLAY (overlay)->next == NULL);
+
/* Delete the overlay if it is empty after clipping and has the
evaporate property. */
if (n_beg == n_end && !NILP (Foverlay_get (overlay, Qevaporate)))
- return unbind_to (count, Fdelete_overlay (overlay));
+ { /* We used to call `Fdelete_overlay' here, but it causes problems:
+ - At this stage, `overlay' is not included in its buffer's lists
+ of overlays (the data-structure is in an inconsistent state),
+ contrary to `Fdelete_overlay's assumptions.
+ - Most of the work done by Fdelete_overlay has already been done
+ here for other reasons. */
+ drop_overlay (XBUFFER (buffer), XOVERLAY (overlay));
+ return unbind_to (count, overlay);
+ }
/* Put the overlay into the new buffer's overlay lists, first on the
wrong list. */