From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#14724: 24.3.50; `isearch-open-necessary-overlays' handling of overlay property 'isearch-open-invisible' Date: Wed, 26 Jun 2013 19:38:19 -0700 (PDT) Message-ID: <5579ad7c-967c-4635-b9cc-758968faddb1@default> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1372300748 5899 80.91.229.3 (27 Jun 2013 02:39:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 27 Jun 2013 02:39:08 +0000 (UTC) Cc: 14724@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jun 27 04:39:08 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 1Us271-0002HT-J3 for geb-bug-gnu-emacs@m.gmane.org; Thu, 27 Jun 2013 04:39:07 +0200 Original-Received: from localhost ([::1]:44006 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Us271-00054B-7n for geb-bug-gnu-emacs@m.gmane.org; Wed, 26 Jun 2013 22:39:07 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37611) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Us26x-000545-Ve for bug-gnu-emacs@gnu.org; Wed, 26 Jun 2013 22:39:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Us26x-00084p-1r for bug-gnu-emacs@gnu.org; Wed, 26 Jun 2013 22:39:03 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:49852) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Us26w-00084l-Uf for bug-gnu-emacs@gnu.org; Wed, 26 Jun 2013 22:39:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Us26w-0004kR-9I for bug-gnu-emacs@gnu.org; Wed, 26 Jun 2013 22:39:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 27 Jun 2013 02:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 14724 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 14724-submit@debbugs.gnu.org id=B14724.137230071318211 (code B ref 14724); Thu, 27 Jun 2013 02:39:02 +0000 Original-Received: (at 14724) by debbugs.gnu.org; 27 Jun 2013 02:38:33 +0000 Original-Received: from localhost ([127.0.0.1]:44167 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Us26S-0004je-B0 for submit@debbugs.gnu.org; Wed, 26 Jun 2013 22:38:32 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:21991) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Us26O-0004jN-8e for 14724@debbugs.gnu.org; Wed, 26 Jun 2013 22:38:28 -0400 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5R2cL8U011113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 27 Jun 2013 02:38:22 GMT Original-Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5R2cKY8013616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Jun 2013 02:38:20 GMT Original-Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5R2cK6G008265; Thu, 27 Jun 2013 02:38:20 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7 (607090) [OL 12.0.6668.5000 (x86)] X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.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:75628 Archived-At: > > The code would be more robust if it would gracefully handle (1) an > > non-functional value and perhaps >=20 > Wouldn't such a non-function non-nil value reflect an error in an > Elisp package? Yes, normally. In Elisp code, whether a package or not, and whether distri= buted by Emacs Dev or not. > If so, why should we silence it? It would allow 3rd-party code that might not be correct in this regard to a= t least allow Isearch to continue to function normally otherwise. The only reasonable value is a function, since we immediately invoke funcal= l with it. I'm guessing it might not be obvious to someone where the error= lies. It costs nothing for the code to protect itself from funcalling a non-funct= ion here and thus fail gracefully with a no-op. Someone trying to use this= feature will as likely dig in to figure out the problem with a non-action = as with an error, but users would at least not be impacted. Of course I agree that raising an error for incorrect code is typically TRT= . I'm not sure it is in this case. See what I said about `isearch-open-in= visible-temporary', which is different in that it is not set up in distant = code but is internal to isearch.el. > > For (1+2), that could be wrapped in `ignore-errors'. >=20 > I thing I disagree with ignore-errors here (at least, I don't think such > errors are normal, so they shouldn't be silenced), but using > with-demoted-errors could make sense if errors in this code could make > isearch non-functional. Is that the case? An error is raised; that's all - Isearch is not broken by it. Yes, `with-d= emoted-errors' makes more sense. The same considerations apply here as for= a non-function: better a no-op (a msg is OK) than an error, I think. Whatever you decide is fine with me. I'm essentially bringing it to your a= ttention. Perhaps Juri has some input on this?