RE: Negative occur

[Drew Adams]

> I'm not talking about Icicles (that's why I mentioned occur-1
> and occur-engine originally), sorry if I didn't state that
> clearly.  I just thought that since you recommended the
> filter-later approach, Icicles didn't support
> predicates, so it made sense to follow up to you.

A misunderstanding, then. I said "In Icicles, just do this..." and you
replied "Both solutions will be slower...".

I didn't recommend any filter-later approach.

In fact, I said "I realize that [spamfilter's] suggestion is that this be
added to Emacs. I agree.". By which I meant that it makes sense to let
`occur' do this itself. And in an efficient way - the first time around (not
via an after-the-fact filter).

> DA> As always, the usefulness of a tool depends on what you use
> DA> it for. If you want to search a 5 terabyte file, then
> DA> interactivity might suffer with some approaches (depending
> DA> on your hardware... and, especially, depending on your
> DA> regexp). But, as always, the devil is in the details.
>
> I can see that between a O(n) and O(n log(n)) algorithm for small data
> sets, but when the difference is that one approach copies every line and
> the other doesn't, while they achieve the same result, it literally
> bothers me to recommend the former approach just because the API doesn't
> support the latter.  So I'll propose the API change to emacs-devel.

Makes sense to me. I thought that Tamas (oops, spamfilter) was already
suggesting that. If `occur' is made to handle non-matches, it should
certainly do that efficiently.