help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Negative occur


From: Drew Adams
Subject: RE: Negative occur
Date: Wed, 28 Nov 2007 14:52:15 -0800

> >> > 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 via email to

[Prev in Thread] Current Thread [Next in Thread]