unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "Ted Zlatanov" <tzz@lifelogs.com>, <help-gnu-emacs@gnu.org>
Subject: RE: Negative occur
Date: Wed, 28 Nov 2007 14:52:15 -0800	[thread overview]
Message-ID: <DNEMKBNJBGPAOPIJOOICAEKJEBAA.drew.adams@oracle.com> (raw)
In-Reply-To: <86tzn62obk.fsf@lifelogs.com>

> >> > 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.

  reply	other threads:[~2007-11-28 22:52 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.4263.1196269422.18990.help-gnu-emacs@gnu.org>
2007-11-28 18:54 ` Negative occur Ted Zlatanov
2007-11-28 22:52   ` Drew Adams [this message]
     [not found] <mailman.4315.1196357177.18990.help-gnu-emacs@gnu.org>
2007-11-29 18:27 ` spamfilteraccount
2007-12-05 17:44   ` Mathias Dahl
     [not found] <mailman.4275.1196290389.18990.help-gnu-emacs@gnu.org>
2007-11-29 15:58 ` Ted Zlatanov
2007-11-29 17:25   ` Drew Adams
2007-11-28 10:15 spamfilteraccount
2007-11-28 10:21 ` David Kastrup
2007-11-28 10:53   ` spamfilteraccount
2007-11-28 17:03     ` Drew Adams
2007-11-29 11:44     ` spamfilteraccount

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DNEMKBNJBGPAOPIJOOICAEKJEBAA.drew.adams@oracle.com \
    --to=drew.adams@oracle.com \
    --cc=help-gnu-emacs@gnu.org \
    --cc=tzz@lifelogs.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).