bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#60058: 29.0.60; overlay-lists does not conform to its docstring


From: Eli Zaretskii
Subject: bug#60058: 29.0.60; overlay-lists does not conform to its docstring
Date: Wed, 14 Dec 2022 14:23:31 +0200

> From: Kai Ma <justksqsf@gmail.com>
> Date: Wed, 14 Dec 2022 13:22:07 +0800
> 
> The docstring of overlay-lists states that the return value is a cons
> pair, and the CDR is not always nil.  However, the code does not do what
> it claims to do.
> 
>     DEFUN ("overlay-lists", Foverlay_lists, Soverlay_lists, 0, 0, 0,
>            doc: /* Return a pair of lists giving all the overlays of the 
> current buffer.
>     The car has all the overlays before the overlay center;
>     the cdr has all the overlays after the overlay center.
>     Recentering overlays moves overlays between these lists.
>     The lists you get are copies, so that changing them has no effect.
>     However, the overlays you get are the real objects that the buffer uses. 
> */)
>       (void)
>     {
>       Lisp_Object overlays = Qnil;
>       struct itree_node *node;
>     
>       ITREE_FOREACH (node, current_buffer->overlays, BEG, Z, DESCENDING)
>         overlays = Fcons (node->data, overlays);
>     
>       return Fcons (overlays, Qnil);
>     }
> 
> This change in behavior has led to at least one breakage in the wild:
> symbol-overlay cannot count overlays correctly.
> 
> I think there is a problem either in the code or in the docstring.

The problem is not in overlay-lists, IMO, the problem (if there is
one) is in overlay-recenter: it is a no-op in Emacs 29 and later.

I think we have two alternatives:

  . reimplement overlay-recenter for the new overlay representation
  . document that overlay-recenter is a no-op, as an incompatible Lisp
    change, and recommend that Lisp program simply stop relying on its
    effect in Emacs >= 29: after all, the sole purpose of that
    function was to speed up overlay access, and now this is not needed

I tend to do the latter.  Lars, Stefan, any ideas or comments?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]