Re: new style Emacs compile

[Stefan Monnier]

>> > 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.

Ahem!

> 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.

Backward compatibility can be achieved via:
1 - using another variable and "compiling" error-regexp-alist to it
    just like font-lock-keywords is currently auto-generated by
    "compiling" error-regexp-alist to it.
    Some sophisticated uses of error-regexp-alist (where the list
    is modified on-the-fly) might not work any more but I don't know
    of any code that does it and I'm not even sure it currently
    works either.
2 - error-regexp-alist does not occupy the whole space of lisp sexps,
    so we can extend it already.  E.g. something like:

    Either (REGEXP FILE-IDX LINE-IDX [COLUMN-IDX FILE-FORMAT ...])
    or (REGEXP FILE-IDX ERR-FUN [ARGS ...])
    or (REGEXP [:keyword arg ...] FILE-IDX LINE-IDX ...)
    or ([:keyword arg ...] REGEXP FILE-IDX LINE-IDX ...)
    or ((REGEXP FILE-IDX LINE-IDX ...) ...)
    or ...

    The first form is the current documented one.
    The second is the currently supported but undocumented one, used
    by sml-mode and maybe others (I came across it by reading compile.el
    so someone must have put it there for some other reason before).
    The third, fourth, and fifth are three possible new formats,
    there are manny more, of course.

> 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 don't see any reason why it should be inherently slower.
Using a single regexp while matching is probably a good idea, but that
does not mean that the spec needs to be a single regexp: we could
combine them dynamically.
Of course, that can have drawbacks as well: sub-group numbers are more
difficult to compute, we might hit the limit of 128 subgroups, or we might
hit a regexp-size limit (XEmacs's compile.el does/did something like that
and had problems with the regexp-size limit although I think it was for
error-regexp-alist or even for the sum of all regexps, rather than just for
the directory tracking which is typically smaller).

>> 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?

It also makes compile.el ignore the message even if it might have matched an
error-regexp (which is why it can be faster).

> 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.

There might indeed be an alternative approach.
Also, other than for TeX, I don't know where it could be used, and I don't
know of any current user of this feature (the only use I can find in google
is a bug report pointing out that the nomessage thingy broken in Emacs-20.5
(it has been fixed since then)).
Obviously, it's a very minor issue.

> 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 ')'?

The current parser in tex-mode.el fails so often (for me anyway) that
I never use it.  I have worked on fixing it, but it's not ready for
install yet.  Furthermore, my "better" tex-mode parsing is done in elisp,
not via error-regexp-parsing.

> 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.

I wouldn't worry about it.

>> 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.

It'd be better to just change diff.el so it uses diff-mode.el
rather than compile.el.  I don't think the alternating behavior is
very useful (or convenient for that matter).


        Stefan