Occur: "no matches for <regexp>": KILL *occur*, please

Occur: "no matches for <regexp>": KILL *occur*, please

[David Combs]

You do an M-x occur, which succeeds and gives you a *Occur*.

Now you do a different M-x occur, and there's NO matches
this second time.

So what does emacs do?  Leaves *Occur* untouched, but
does report "no matches for ..." down in the minibuf.

Well, that minibuf is by definition the furthest-away thing
on the emacs-screen -- down at the very bottom.  And there's
only *one* of them, regardless of the number of windows
on-screen at a given time.

Like, if both the file you're occurring on and the *Occur*
file are "far" away from the minibuf, YOU WON'T LIKELY SEE
the "nothing found" minibuf-msg.

Thus, you *might* have a look at the existing *Occur*, and
(incorrectly) *think* that it's showing the results of your *successful*
second try -- totally wrong, of course.

----- WHAT TO DO?

(1) you could just kill-off that prior *Occur*.  Unambiguous action.


(2) you could instead *keep* that prior *Occur* -- but MODIFY
the buffer-content to somehow say "am from some PRIOR M-x occur".

  Maybe via some standout-color, maybe via big x "ascii-drawn"
over it, or the like.


Of course, take into consideration whether the prior occur
was on the *same* or a *different* file from what the
*unsuccessful* M-x occurs were run on.

   (Don't ask me "in what way do you suggest we take
     that matter into consideration" -- am far too
     tired to think logically about that one.)


THANKS,

David

Re: Occur: "no matches for <regexp>": KILL *occur*, please

[Stefan Monnier]

> So what does emacs do?  Leaves *Occur* untouched, but
> does report "no matches for ..." down in the minibuf.

I think it's good that it preserves the old content of the occur buffer.
But maybe it could (ding) at the same time as it says "no match" to make it
more obvious.
Anyway, it's a job for gnu.emacs.bug.


        Stefan