[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: new style Emacs compile
From: |
Stefan Monnier |
Subject: |
Re: new style Emacs compile |
Date: |
27 Nov 2003 15:30:54 -0500 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 |
> 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