Should overlays evaporate by default?

[Peter Whaite]

Robert J. Chassell <address@hidden> wrote:
> [After running the same RMAIL for several days, deletions slow; but
> they do not slow the first day.]
> 
> Success so far!
> 
> On 6 May 2005, Stefan Monnier said
> 
>     Maybe we just need to make goto-address mark its overlay with the
>     `evaporate' propert so they disappear as soon as they beomce
>     empty.
> 
> and provided a patch.

Last year I reported a similar problem with mh-e (see below).

Perhaps it would be better for overlays to evaporate by default.

I can only think of one case where its not better, and that's where the
contents of an editable field are deleted and new contents reinserted.
If the overlay evaporates the field disappears, but the bug is
immediately obvious and quickly fixed.

On the other hand, for the case where overlays are used to decorate
buffer contents, the consequence (massive memory leakage) is not
obvious, and goes undetected.  I suspect that this case is far more
common.

For reference here is what I said back on 15 July 2004:
>
> MH-E uses parts of GNUS to display messages, and the overlays used by
> GNUS do not have the evaporate property set, and so do not get deleted
> when the mh-show buffer is erased in preparation for the next message
> (see below).
> 
> Yes MH-E, and any other packages that use these utilities, could be
> changed to explicitly delete overlays when reusing buffers, but it would
> be easier for maintainers and future package writers if the GNUS
> overlays would evaporate.
> 
> It would not surprise me if other packages using overlays to decorate
> buffer contents also leak.
> 
> The real problem is that anyone using overlays to decorate the contents
> of a reusable buffer is required to know that they must either
> explicitly set the evaporate property on any overlays they create, or
> explicitly delete overlays when using erase-buffer, or both.
> 
> This requirement is not obvious.  There should be a note in the
> erase-buffer documentation pointing out that only overlays with the
> evaporate property will be deleted, and with a reference to the new
> remove-overlays function.
> 
> I think it preferable that erase-buffer also remove the overlays.  Right
> now it results in _all_ the non-evaporating overlays being reduced to
> zero length at the begining of the buffer.  Inserting text into the
> buffer cannot ressurect them unless they have a non-default end
> advance behaviour.  I guess erase-buffer could be selective about which
> overlays it removes, but that sounds like overkill as I doubt anyone
> intentionally uses overlays and erase-buffer that way.
> 
> Here is the result of my tests on the MH-E message show buffer after
> using it to browse several email messages...
> 
> (pp (save-current-buffer
>   (set-buffer (get-buffer-create "show-+inbox"))
>   (mapcar (lambda (ov) (list (overlay-start ov) (overlay-end ov)
>                            (overlay-properties ov)))
>         (overlays-in (point-min) (point-max)))
>   ))
> 
> Overlays used in current message...
> 
> ((515 558
>       (face gnus-cite-face-2))
>  (443 512
>       (face gnus-cite-face-2))
>  (378 437
>       (face gnus-cite-face-2))
>  (302 374
>       (face gnus-cite-attribution-face))
>  (302 374
>       (face gnus-cite-face-2))
> 
> Overlays used in previous messages...
> 
>  (1 1
>     (face gnus-cite-face-2))
>  (1 1
>     (face gnus-cite-face-2))
>  (1 1
>     (face gnus-cite-attribution-face))
>  (1 1
>     (face gnus-cite-face-3))
>  (1 1
>     (keymap
>      (keymap
>       (mouse-2 . smiley-mouse-toggle-buffer)
>       (down-mouse-2 . ignore))
>      help-echo "mouse-2: toggle smilies in buffer" smiley t mouse-face 
> highlight display
>      (when smiley-active image :type pbm :file 
> "/usr/local/share/emacs/21.3.50/lisp/gnus/smile.pbm" :ascent center)))
>     (face gnus-cite-face-2))
> 
>   ...and many, many, more
> )

-- 
Peter Whaite (http://whaite.ca)