emacs-pretest-bug
[Top][All Lists]
Advanced

[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/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]