Re: new style Emacs compile

[Stefan Monnier]

> Until this is ready for switching over I try to stay as compatible as
> possible with the existing compile.el.  This is especially true of the
> huge error-regexp-alist.  When I near completion I will transform that to
> the new data format.  Right now I have only broken the format sublist,
> which none of the standard matchers uses anyways.

> This means that, like the old compile did, I still tack ^ to the beginning
> of each regexp.  I will however keep the algorithm clear of this
> assumption, so it'll be easy to change.  Then messages can match anything
> font-lock is capable of.

Like RMS said, it's not a high-priority thing.  I just thought that if (as
I understand it) your rewrite uses re-search-forward instead of looking-at,
it should be pretty easy to add such features.  But I fully agree that the
goal no 1 is backward compatibility.

I'd expect the hard part is to deal with the `ignore' parts
(i.e. the compilation-nomessage-regexp-alist variable).

>> The typical example is TeX where error messages can look like:
>> 
>> (file1 (file2
>> Some error message about the second file line 30
>> Some sample text from line 30 that includes funny chars like )
>> )
>> Some other error message [this time about the first file because of the
>> close-paren above]
>> )

> I's been years since I've used TeX.  I don't know how to recognize
> a file-ending ')'.  Do they always come right after a file-name or at the
> beginning of a new line, singly or several grouped together?

They can come "anywhere", so it's important to recognize text that needs to
be ignored (typically text copied straight from the source file).

>> As well as sml-mode (still not bundled with Emacs :-( ) which cleverly [hey!
>> I wrote it!] uses hooks in compilation-error-regexp-alist to do correct
>> handling of things like "error between line30-col5 and line45-col10" (point
>> is moved to one end, mark to the other, and the mark is activated, so if you
>> use transient-mark-mode the region is highlighted).

> Hey, that's a clever trick!  It shouldn't be hard to generally put that
> functionality into compilation-mode instead of the current brief
> highlighting of a whole line.  Then all message matchers could just
> configure which match index is the from and the to line, likewise for
> columns.  It would save going over the result with a hook and fixing up
> the text-properties.

One way is to make sure the new code still supports the old hook where
the LINE-IDX part of an entry in error-alist can be a function rather
than an integer.
Of course another way is to make the old sml-proc.el hack unnecessary.
That would be preferable, indeed.


        Stefan