[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: new style Emacs compile
From: |
Daniel Pfeiffer |
Subject: |
Re: new style Emacs compile |
Date: |
Fri, 28 Nov 2003 18:10:47 +0100 |
Saluton, Moin,
Stefan Monnier <address@hidden> skribis:
> > 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.
It can't be backwards compatible. The error-regexp-alist has too little
information for the new features, and no free space where the new information
can go. And it assumes ^ at the beginning of each regexp, so they will all
have to be slightly reworked, when this assumption is dropped. And I agree it
should be dropped.
I have also had to put all directory matching into a single regexp (instead of
4 before). This is the only way font-lock can assign directory properties in
one pass. That in turn is needed to get the nesting right when loading a
compilation output file. If this is deemed unacceptable (it makes multilingual
matching harder to achieve) then it would have to be realized with a function
-- which would be slower.
> I'd expect the hard part is to deal with the `ignore' parts
> (i.e. the compilation-nomessage-regexp-alist variable).
The doc says that this is needed to make the parsing faster -- I assumed for
nothing else. I can't imagine that font lock will be faster if it has more
regexps to match?
If someone needs this for something else, it could be achieved with a
font-lock-face property (whatever the one which tells font-lock not to fontify
here is called) or OVERRIDE 'keep on all message matchers.
> >> 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]
> >> )
> They can come "anywhere", so it's important to recognize text that needs to
> be ignored (typically text copied straight from the source file).
Can you put a rule for this in words? Or maybe someone can explain the idea
behind the existing TeX message parser to me? Is it adequate at all, or does
it fail in 30% of messages containing a ')'?
> >> 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.
Ah that's where you put the hook. This seems undocumented, and is not used by
any standard libraries. However, if somebody wants it, I could run a hook for
every matched message.
> Of course another way is to make the old sml-proc.el hack unnecessary.
> That would be preferable, indeed.
I'll try to do that. This will also be usefull for diff. Diff has one more
challenge, in that I must altenate between two filenames. Currently this is
not done, but then the current diff command is not really useful.
coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer
--
lerne / learn / apprends / läramå Esperanto:
http://lernu.net/