unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: Stefan Monnier via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
To: help-gnu-emacs@gnu.org
Subject: Re: When are unused overlays garbage collected?
Date: Mon, 24 May 2021 13:07:38 -0400	[thread overview]
Message-ID: <jwv4kesxdzy.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: 87v978u3nd.fsf@mbork.pl

> My guess would be that if the overlay is "deleted" (so it is not
> attached to any buffer, either by means of `delete-overlay' or when its
> buffer is killed) /and/ it can't be referenced from Elisp (e.g., there
> is no variable bound to it).  This would make sense, because even if
> there is no variable bound to an overlay which is not deleted, you can
> still get a reference to it using any of the overlay-finding functions
> (`overlays-at' or `overlays-in').

Sounds right, yes.  `delete-overlay` just disconnects the overlay from
the buffer in which it was placed.  As long as an overlay is placed in
a buffer, then it is still reachable (via internal variables inside the
buffer, and via `overlays-at' or `overlays-in') and it can have visible
effects on screen.

Markers share some of their implementation with overlays, but because
markers do not affect the display and because there is nothing
corresponding to `overlays-at' or `overlays-in', Emacs goes through the
trouble of GC'ing those markers which are still reachable via the
buffer's internal variables (its list of markers) as long as they're not
reachable some other way, of course.

So it's OK to create markers are then forget about them, but it's not
OK to create overlays and then forget about them: you need to manually
`delete-overlay` when you're done with them otherwise they'll accumulate
in the buffer.


        Stefan




  parent reply	other threads:[~2021-05-24 17:07 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-24  5:00 When are unused overlays garbage collected? Marcin Borkowski
2021-05-24  5:05 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-05-24  6:33   ` Marcin Borkowski
2021-05-24 12:27 ` Eli Zaretskii
2021-05-26  4:53   ` Marcin Borkowski
2021-05-26  7:23     ` tomas
2021-05-26 15:36       ` Stefan Monnier via Users list for the GNU Emacs text editor
2021-05-26 16:52         ` tomas
2021-05-26 12:30     ` Eli Zaretskii
2021-05-27 16:20       ` Marcin Borkowski
2021-05-27 16:41         ` Eli Zaretskii
2021-05-28 19:38           ` Marcin Borkowski
2021-05-24 17:07 ` Stefan Monnier via Users list for the GNU Emacs text editor [this message]
2021-05-26  5:01   ` Marcin Borkowski
2021-05-26 12:34     ` Eli Zaretskii
2021-05-27 16:23       ` Marcin Borkowski
2021-05-26 14:48     ` Stefan Monnier
2021-05-27 16:26       ` Marcin Borkowski
2021-05-27 21:42         ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwv4kesxdzy.fsf-monnier+emacs@gnu.org \
    --to=help-gnu-emacs@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).