From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: Info mutilates user overlays. Date: Wed, 1 Oct 2003 09:49:11 -0500 (CDT) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200310011449.h91EnBN28933@raven.dms.auburn.edu> References: <200310010216.h912Ge027788@raven.dms.auburn.edu> NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1065043286 21028 80.91.224.253 (1 Oct 2003 21:21:26 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 1 Oct 2003 21:21:26 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed Oct 01 23:21:24 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1A4oPT-0004em-00 for ; Wed, 01 Oct 2003 23:21:23 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1A4oPT-0003pz-01 for ; Wed, 01 Oct 2003 23:21:23 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1A4nxh-0002rn-OR for emacs-devel@quimby.gnus.org; Wed, 01 Oct 2003 16:52:41 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1A4nxU-0002qL-MZ for emacs-devel@gnu.org; Wed, 01 Oct 2003 16:52:28 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1A4nwu-0002ku-Mt for emacs-devel@gnu.org; Wed, 01 Oct 2003 16:52:23 -0400 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.24) id 1A4iLd-0007ak-Fi for emacs-devel@gnu.org; Wed, 01 Oct 2003 10:53:01 -0400 Original-Received: from raven.dms.auburn.edu (raven.dms.auburn.edu [131.204.53.29]) by manatee.dms.auburn.edu (8.12.10/8.12.10) with ESMTP id h91EqxAJ015853; Wed, 1 Oct 2003 09:52:59 -0500 (CDT) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.6+Sun/8.11.6) id h91EnBN28933; Wed, 1 Oct 2003 09:49:11 -0500 (CDT) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: monnier@IRO.UMontreal.CA In-reply-to: (message from Stefan Monnier on 01 Oct 2003 08:22:39 -0400) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:16833 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:16833 Stefan Monnier wrote: You say this is unexpected, but you don't say what you expected. The text of the buffer has changed, so the overlay has of course been moved, as is always the case. On second thought yes. Also, there are worse problems in Info than this one, related to the same fact. Position registers get treated exactly like overlays and hence are unusable. Bookmarks at first seem to work, but malfunction. After you save one bookmark, say in (emacs)Secondary Selection, then all subsequent bookmarks in different Info files get saved under "Secondary Selection". The user believes he has saved, say 10 bookmarks, but all but the last are gone and it is saved under a misleading name. Position registers and bookmarks are mainly useful in large files, so the one place where they would be the most useful (if they worked) are Info files. In as far as Miles' question is concerned, I am using overlays to highlight regions with a non-nil text or overlay property, but I sometimes use overlays to highlight all kinds of stuff. I can always rehighlight. That is somewhat inconvenient, but less inconvenient than the register-bookmark stuff. There is one more problem with that overlay repositioning. Maybe it applies to *Help* buffers as well. Unreferenced deleted overlays are inaccessible (in as far as I know) and hence are garbage, which (I would guess) gets garbage collected. But these repositioned overlays, even if unreferenced, remain accessible through (overlays-in 1 2), hence are not garbage and would (I guess) never get collected. If some package spews out a lot of these overlays and fails to delete them during updates, as a result of narrowing, can that get a problem? Sincerely, Luc.