From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Berman Newsgroups: gmane.emacs.bugs Subject: bug#13648: 24.3.50; remove-overlays bugs Date: Thu, 07 Feb 2013 20:16:07 +0100 Message-ID: <87y5f09bpk.fsf@rosalinde.fritz.box> References: <8738x8b1pa.fsf@rosalinde.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1360264643 1361 80.91.229.3 (7 Feb 2013 19:17:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 7 Feb 2013 19:17:23 +0000 (UTC) Cc: 13648@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Feb 07 20:17:43 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1U3WyV-00031G-M5 for geb-bug-gnu-emacs@m.gmane.org; Thu, 07 Feb 2013 20:17:35 +0100 Original-Received: from localhost ([::1]:47987 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U3WyC-0004l8-MB for geb-bug-gnu-emacs@m.gmane.org; Thu, 07 Feb 2013 14:17:16 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:35614) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U3Wy3-0004iv-Lz for bug-gnu-emacs@gnu.org; Thu, 07 Feb 2013 14:17:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U3Wy0-0002rF-1X for bug-gnu-emacs@gnu.org; Thu, 07 Feb 2013 14:17:07 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:36852) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U3Wxz-0002qx-UO for bug-gnu-emacs@gnu.org; Thu, 07 Feb 2013 14:17:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1U3Wxx-0000kp-Qa for bug-gnu-emacs@gnu.org; Thu, 07 Feb 2013 14:17:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stephen Berman Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 07 Feb 2013 19:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13648 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 13648-submit@debbugs.gnu.org id=B13648.13602645742836 (code B ref 13648); Thu, 07 Feb 2013 19:17:01 +0000 Original-Received: (at 13648) by debbugs.gnu.org; 7 Feb 2013 19:16:14 +0000 Original-Received: from localhost ([127.0.0.1]:42316 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U3WxB-0000jh-T6 for submit@debbugs.gnu.org; Thu, 07 Feb 2013 14:16:14 -0500 Original-Received: from mout.gmx.net ([212.227.15.18]:52891) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1U3Wx9-0000jY-2f for 13648@debbugs.gnu.org; Thu, 07 Feb 2013 14:16:12 -0500 Original-Received: from mailout-de.gmx.net ([10.1.76.17]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MGDc1-1U89NN3npn-00FG7c for <13648@debbugs.gnu.org>; Thu, 07 Feb 2013 20:16:10 +0100 Original-Received: (qmail invoked by alias); 07 Feb 2013 19:16:10 -0000 Original-Received: from i59F57850.versanet.de (EHLO rosalinde.fritz.box) [89.245.120.80] by mail.gmx.net (mp017) with SMTP; 07 Feb 2013 20:16:10 +0100 X-Authenticated: #20778731 X-Provags-ID: V01U2FsdGVkX1/d+KoxIffdbKT3Y6kgt5TnYnkdY6Udj4YZfdKoRP k7oDpTrwbJ7VXC In-Reply-To: (Stefan Monnier's message of "Thu, 07 Feb 2013 11:42:46 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-Y-GMX-Trusted: 0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:70827 Archived-At: On Thu, 07 Feb 2013 11:42:46 -0500 Stefan Monnier wrote: >> The reason for the first problem is that remove-overlays tests the >> overlay value with eq, which fails for all strings [...] > > No, it won't fail on all strings. You just need to pass it the same > string you added to the overlay, rather than a copy of it. > I.e. this is not a bug. Damn, I get tripped up by that a lot. And the fact that the empty string is an exception doesn't help to keep the difference in mind. Still, it is rather cumbersome to include appropriate let-bindings or calls to overlay-get for each string value in each use of remove-overlays, as opposed to adding a single equal-check to that. >> invocation of remove-overlays is legitimate), the logic of the code is >> that the NAME and VAL arguments are either both nil or both non-nil, > > Indeed. > >> which conflicts with the semantics of the &optional keyword. > > Right. We should document it in the docstring. > >> This means that the last call of remove-overlays in the above sexp >> would clear any after-string overlays, regardless of their value. > > Normally we don't distinguish "an property FOO of value nil" and "no > property FOO". So I think what would make sense is to say that if VAL > is nil, then we remove any overlay whose NAME property is non-nil > (i.e. the exact inverse from what we currently do). > > This said, the reason why I have not implemented this case of NAME being > specified while VAL is left unspecified is because I haven't come up > with a need for it. So I'd be interested to hear the backstory of > why/where you need it. To be honest, I'm not sure I do need it. I have code that inserts before-string overlays with different values, some fixed and some dynamically generated, and when these overlays need to be cleared, it would be easier to just refer to the before-string property. But the way I use the overlays, it actually suffices to leave out both the property and the value, i.e. just remove all overlays in the region. At first I thought that's not safe enough, because there could be other other overlays at the same locations but with different properties, but in fact I haven't needed that yet. But I guess the main thing that confused me was the conflict with the semantics of &optional, and since it seems easy enough to avoid, I think it would be better than just documenting the conflict. Steve Berman