From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.help Subject: RE: Negative occur Date: Wed, 28 Nov 2007 14:52:15 -0800 Message-ID: References: <86tzn62obk.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1196290415 17121 80.91.229.12 (28 Nov 2007 22:53:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 28 Nov 2007 22:53:35 +0000 (UTC) To: "Ted Zlatanov" , Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Nov 28 23:53:42 2007 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1IxVmm-0000On-VW for geh-help-gnu-emacs@m.gmane.org; Wed, 28 Nov 2007 23:53:41 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IxVmX-0007xP-Ec for geh-help-gnu-emacs@m.gmane.org; Wed, 28 Nov 2007 17:53:25 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IxVmG-0007vk-CM for help-gnu-emacs@gnu.org; Wed, 28 Nov 2007 17:53:08 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IxVmF-0007um-Jk for help-gnu-emacs@gnu.org; Wed, 28 Nov 2007 17:53:08 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IxVmF-0007uZ-Ey for help-gnu-emacs@gnu.org; Wed, 28 Nov 2007 17:53:07 -0500 Original-Received: from agminet01.oracle.com ([141.146.126.228]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IxVmF-0007tZ-7U for help-gnu-emacs@gnu.org; Wed, 28 Nov 2007 17:53:07 -0500 Original-Received: from agmgw2.us.oracle.com (agmgw2.us.oracle.com [152.68.180.213]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id lASMr3ra001663; Wed, 28 Nov 2007 16:53:04 -0600 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by agmgw2.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id lASFND2N019179; Wed, 28 Nov 2007 15:53:03 -0700 Original-Received: from dhcp-4op11-4op12-west-130-35-178-158.us.oracle.com by acsmt351.oracle.com with ESMTP id 3393439721196290330; Wed, 28 Nov 2007 14:52:10 -0800 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <86tzn62obk.fsf@lifelogs.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:49663 Archived-At: > >> > You could try running "occur" with the pattern "^" (which matches > >> > every line), then prune the results with M-x delete-matching-lines RET [spamfilteraccount suggested that Emacs should have this as part of `occur'...] > DA> I realize that your suggestion is that this be added to > DA> Emacs. I agree. FYI - In Icicles, just do this: C-' foobar C-~ > DA> That shows and lets you visit all lines that do not match the > DA> regexp "foobar". > > Both solutions will be slower on a large buffer than they should be. What does "slower than they should be" mean? How slow should they be? How slow are they in fact? How large is a large buffer? How do you judge that "they" (two totally different approaches and implementations) are slower than they should be? > A real inversion parameter, either as a predicate function or a variable, > passed lexically or as a parameter to the occur-engine function call, is > necessary. Necessary? For what? Why necessary? These are generalizations that don't help. Despite the name, `icicle-occur' (C-') doesn't even use "the occur-engine". If you are suggesting that Emacs `occur' should let you pass a predicate and incorporate it in a single search pass, that might be worthwhile, but it is in any case irrelevant for `icicle-occur. > A predicate function is probably best as it can express > transformations more complex than identity and negation. In Icicles, you can also apply a predicate for searching, and you can do that on the fly too. You can combine any number of predicates that way. You can mix regexps and predicates for searching. See http://www.emacswiki.org/cgi-bin/wiki/Icicles_-_Progressive_Completion#Predi cates. Your statements are vague, but I'm guessing that what you're really trying to say is that it is often more efficient to apply a predicate earlier rather than later (filter promotion), which is true. Icicles also lets you do that, BTW, to define your own Icicles search command that incorporates a predicate from the outset (as opposed to using it as a filter afterward). And this too can be mixed with regexp searching. An example of this are the definitions of the Icicles Imenu commands that let you browse definitions of Emacs commands only or non-interactive functions only: an Imenu regexp to recognize function definitions is combined with a `commandp' test. http://www.emacswiki.org/cgi-bin/wiki/Icicles_-_Other_Search_Commands#Define SearchCommands However, the real question about efficiency is whether something is efficient _enough_. The Icicles approach is designed for interactive use, which is why it emphasises changing search patterns (and predicates) on the fly. It works fine with any buffers I've ever used, some of which are pretty darn big. (How big is big? I just searched a 19MB buffer with no effect on interactivity.) As always, the usefulness of a tool depends on what you use it for. If you want to search a 5 terabyte file, then interactivity might suffer with some approaches (depending on your hardware... and, especially, depending on your regexp). But, as always, the devil is in the details.