From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stuart D. Herring" Newsgroups: gmane.emacs.devel Subject: Re: Why should interactive search results raise errors? Date: Thu, 4 May 2006 08:34:30 -0700 (PDT) Message-ID: <36883.128.165.123.132.1146756870.squirrel@webmail.lanl.gov> References: <4458D9D1.5000907@student.lu.se> <87vesn83ul.fsf@mit.edu><4458DF5F.6010309@student.lu.se> <445A0DAB.1070809@student.lu.se> Reply-To: herring@lanl.gov NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: sea.gmane.org 1146756908 6943 80.91.229.2 (4 May 2006 15:35:08 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 4 May 2006 15:35:08 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 04 17:35:06 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Fbfqv-0007ZE-5a for ged-emacs-devel@m.gmane.org; Thu, 04 May 2006 17:34:53 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Fbfqu-00013K-Ms for ged-emacs-devel@m.gmane.org; Thu, 04 May 2006 11:34:52 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Fbfqf-000131-U9 for emacs-devel@gnu.org; Thu, 04 May 2006 11:34:37 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Fbfqe-00012j-9O for emacs-devel@gnu.org; Thu, 04 May 2006 11:34:37 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Fbfqe-00012g-7F for emacs-devel@gnu.org; Thu, 04 May 2006 11:34:36 -0400 Original-Received: from [192.65.95.54] (helo=mailwasher-b.lanl.gov) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1FbfrH-0006Qt-AX for emacs-devel@gnu.org; Thu, 04 May 2006 11:35:15 -0400 Original-Received: from mailrelay1.lanl.gov (mailrelay1.lanl.gov [128.165.4.101]) by mailwasher-b.lanl.gov (8.12.11.20060308/8.12.11/(ccn-5)) with ESMTP id k44FYWf9026753 for ; Thu, 4 May 2006 09:34:32 -0600 Original-Received: from webmail1.lanl.gov (webmail1.lanl.gov [128.165.4.106]) by mailrelay1.lanl.gov (8.12.11.20060308/8.12.11/(ccn-5)) with ESMTP id k44FYUQx029047; Thu, 4 May 2006 09:34:30 -0600 Original-Received: from webmail1.lanl.gov (localhost.localdomain [127.0.0.1]) by webmail1.lanl.gov (8.12.11.20060308/8.12.11) with ESMTP id k44FYU6c002679; Thu, 4 May 2006 09:34:30 -0600 Original-Received: (from apache@localhost) by webmail1.lanl.gov (8.12.11.20060308/8.12.11/Submit) id k44FYU0k002676; Thu, 4 May 2006 08:34:30 -0700 X-Authentication-Warning: webmail1.lanl.gov: apache set sender to herring@lanl.gov using -f Original-Received: from 128.165.123.132 (SquirrelMail authenticated user 196434); by webmail.lanl.gov with HTTP; Thu, 4 May 2006 08:34:30 -0700 (PDT) In-Reply-To: <445A0DAB.1070809@student.lu.se> Original-To: "Lennart Borgman" User-Agent: SquirrelMail/1.4.3a-11.EL3 X-Mailer: SquirrelMail/1.4.3a-11.EL3 X-Priority: 3 (Normal) Importance: Normal X-PMX-Version: 4.7.1.128075 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:53911 Archived-At: > If I want to see if there is any hits at all then a failed search is not > an error. It gives me the information I wanted - whether there are hits > or not. Why should then this be an error? The menu eventually calls `search-forward'. Its doc string begins thus: Search forward from point for STRING. Set point to the end of the occurrence found, and return point. If there is no occurrence of STRING, then this function cannot do what it says it will do, so it must signal an error. Even if we ignore that it says it will return point and return nil from it, it has not set point to anything meaningful, so it should not return normally. Certainly one could define a function with different semantics -- or a flag for an existing function. And we have: Optional third argument, if t, means if fail just return nil (no error). If not nil and not t, move to limit of search and return nil. So perhaps you just want `nonincremental-search-forward' to do (search-forward string nil t)? That's not unreasonable, but then the menu and the underlying command would behave differently. So you could make the default value for the NOERROR argument depend on whether the function was called interactively. But then you have to print some sort of message when the search fails, and (ding) for backwards compatibility -- but only when interactive... It just seems simpler to me to keep the current behavior and use (the proposed) `user-error' or `debug-ignored-errors' as suggested. Davis -- This product is sold by volume, not by mass. If it appears too dense or too sparse, it is because mass-energy conversion has occurred during shipping.