bug#18444: 24.3.93; Error running timer 'compilation-auto-jump' from grep-mode

[David Engster <deng@randomsample.de>]

Glenn Morris writes:
> Glenn Morris wrote:
>
>> (I think it mistakenly tries to find a hit in the "Grep started" line for
>> some reason.)
>
> It's because
>
>    Grep started at Thu Sep 11 16:25:19
>
> matches the first element of grep-regexp-alist:
>
>   "^\\(.+?\\)\\(:[ \t]*\\)\\([1-9][0-9]*\\)\\2"

I've looked into this a bit, and I think this must be fixed in
compile.el itself. The underlying problem is that compile.el will parse
its own output for errors, and this is clearly wrong. This does not only
happen with the the above "Grep started at ..." message, but also the
final line "Grep finished (...) at". Funny thing is that RMS himself had
seen this latter problem as well in 2002, and added the following to
`compilation-handle-exit' (rev. 42924):

    ;; Prevent that message from being recognized as a compilation error.
    (add-text-properties omax (point)
			 (append '(compilation-handle-exit t) nil))

However, that part which actually checked for that text property in
`compilation-parse-errors' somehow vanished in one of the later
refactorings, so that does not work anymore.

I see the following ways to solve this:

- Following RMS initial idea, use a text property to mark text which
  should not be parsed for errors.

- Use buffer-local-variables to remember where the actual
  compilation/grep output starts and ends, and use that as an
  lower/upper bound when calling `compilation--parse-region' in
  `compilation--ensure-parse'.

Whatever we do to fix it, I'm leaning towards doing this in trunk. The
code in compile.el is quite intricate, and it's easy to make
mistakes. Also, this was apparently broken for years...

-David