bug#13369: 24.1; compile message parsing slow because of omake hack

[Mattias Engdegård]

Parsing compilation messages in compilation-mode can be very slow for
large buffers (thousands of error lines); it can take many
seconds. Experiments show that it is the presence of omake in
compilation-error-regexp-alist that causes most of the trouble; removing
it mostly cures the problem.

The omake regexp does not look too troublesome, but there are some
omake-specific hacks in compile.el that are more worrying. In
particular, this code (in compilation-parse-errors) looks suspicious:

      (cond
       ((not (memq 'omake compilation-error-regexp-alist)) nil)
       ((string-match "\\`\\([^^]\\|^\\( \\*\\|\\[\\)\\)" pat)
        nil) ;; Not anchored or anchored but already allows empty  
spaces.
       (t (setq pat (concat "^ *" (substring pat 1)))))

The slightly alarming concept of regexp-matching a regexp aside, this
one doesn't make sense - shouldn't the ^ (following the \|) be escaped?
Apparently the code was at some time changed from

  (when (and (= ?^ (aref pat 0)) ; anchored: starts with "^"
             ;; but does not allow an arbitrary number of leading  
spaces
             (not (and (= ?  (aref pat 1)) (= ?* (aref pat 2)))))

which looks more correct, and conveys the intent somewhat better
(and may be more efficient than the regexp for all I know).

It's not clear to me how the present code could ever have worked.
At the very least the regexp in compilation-parse-errors should
be fixed.

In GNU Emacs 24.1.1 (powerpc-apple-darwin, NS apple-appkit-1038.36)
 of 2012-06-10 on bob.porkrind.org
Windowing system distributor `Apple', version 10.3.949