compilation-error-regexp-alist syntax problems

compilation-error-regexp-alist syntax problems

[Roy Smith]

I'm running ant as my M-X compile command, and trying to get next-error
to parse the output correctly.  The line I want to parse looks like:

    [javac] fileName:lineNumber: message

An example being:

    [javac] /Users/roy/Muse/sandbox.tip/src/SnmpBugDb/data/scripts/test/DataBaseTestCase.java:20: unreport\
ed exception java.io.IOException; must be caught or declared to be thrown

I've tried putting this in my .emacs file:

(add-hook 'compilation-mode-hook 'my-compilation-mode-hook t)
(defun my-compilation-mode-hook ()
  (setq compilation-error-regexp-alist
        (cons '("\\[javac\\] *\(/[^:]+\):\([^:]*\):" 1 2) compilation-error-regexp-alist)
        ))

but the regex doesn't match the line.  At this point, I think the problem is
that I can't figure out how many \'s I need to get the \( and \) to come
out properly in the final alist.

Can somebody set me straight?

Re: compilation-error-regexp-alist syntax problems

[Stefan Monnier]

>         (cons '("\\[javac\\] *\(/[^:]+\):\([^:]*\):" 1 2) compilation-error-regexp-alist)
                                \\(    \\) \\(   \\)

The regexp is written as a string.  \ is both a string and
a regexp operator.  When you write \n in a string it is turned into
linefeed char.  When you write \( it is turned into an open paren
(i.e. just as if there was no backslash), when you write \\ it is turned
into a single backslash.  To pass \( to the regexp engine, you have thus to
write \\ for the backslash and ( or \( for the open-paren.

When entering a regexp interactively in C-u C-s (for example), it's
different because it is not written as an elisp string so the quoting is
unnecessary.


        Stefan

Re: compilation-error-regexp-alist syntax problems

[Roy Smith]

In article 
<jwv8yjlifkp.fsf-monnier+gnu.emacs.help@asado.iro.umontreal.ca>,
 Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> >         (cons '("\\[javac\\] *\(/[^:]+\):\([^:]*\):" 1 2) 
> >         compilation-error-regexp-alist)
>                                 \\(    \\) \\(   \\)
> 
> The regexp is written as a string.  \ is both a string and
> a regexp operator.  When you write \n in a string it is turned into
> linefeed char.  When you write \( it is turned into an open paren
> (i.e. just as if there was no backslash), when you write \\ it is turned
> into a single backslash.  To pass \( to the regexp engine, you have thus to
> write \\ for the backslash and ( or \( for the open-paren.
> 
> When entering a regexp interactively in C-u C-s (for example), it's
> different because it is not written as an elisp string so the quoting is
> unnecessary.
> 
> 
>         Stefan

Hmmm.  That's not working either.  Now I've got this in my .emacs file:

(add-hook 'compilation-mode-hook 'my-compilation-mode-hook t)
(defun my-compilation-mode-hook ()
  (setq compilation-error-regexp-alist
        (cons '("\\[javac\\] *\\(/[^:]+\\):\\([^:]*\\):" 1 2) 
compilation-error-regexp-alist)
        ))

and it's still not finding the right lines.  When I look at the value of 
compilation-error-regexp-alist (C-h v), I get:

Local in buffer *compilation*; global value is
(("\\[javac\\] *\\(/[^:]+\\):\\([^:]*\\):" 1 2)
 [etc]

Re: compilation-error-regexp-alist syntax problems

[Stefan Monnier]

>         (cons '("\\[javac\\] *\\(/[^:]+\\):\\([^:]*\\):" 1 2) 

Try to put point at the beginning of one of the lines and do

M-: (looking-at "\\[javac\\] *\\(/[^:]+\\):\\([^:]*\\):") RET

If it returns nil, there's stilla bug in your regexp.  Maybe you need
to allow spaces before [javac], or I don't know what.

> Local in buffer *compilation*; global value is
> (("\\[javac\\] *\\(/[^:]+\\):\\([^:]*\\):" 1 2)
>  [etc]

Huh?  What is the local value?  Does it include your line?
If not, that's no surprise it's not taken into account.


        Stefan

Re: compilation-error-regexp-alist syntax problems

[Roy Smith]

In article 
<jwvu1284094.fsf-monnier+gnu.emacs.help@asado.iro.umontreal.ca>,
 Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> >         (cons '("\\[javac\\] *\\(/[^:]+\\):\\([^:]*\\):" 1 2) 
> 
> Try to put point at the beginning of one of the lines and do
> 
> M-: (looking-at "\\[javac\\] *\\(/[^:]+\\):\\([^:]*\\):") RET
> 
> If it returns nil, there's stilla bug in your regexp.  Maybe you need
> to allow spaces before [javac], or I don't know what.
> 
> > Local in buffer *compilation*; global value is
> > (("\\[javac\\] *\\(/[^:]+\\):\\([^:]*\\):" 1 2)
> >  [etc]
> 
> Huh?  What is the local value?  Does it include your line?
> If not, that's no surprise it's not taken into account.
> 
> 
>         Stefan

Ah hah!  That's the problem.  It's not in the local version.

Next question, how do I get the local version to include it?

Re: compilation-error-regexp-alist syntax problems

[Stefan Monnier]

> Ah hah!  That's the problem.  It's not in the local version.
> Next question, how do I get the local version to include it?

Looking at `compile-internal', it seems you'll have to do
things differently.
The simplest is:

   (require 'compile)
   (add-to-list 'compilation-error-regexp-alist
                '("\\[javac\\] *\\(/[^:]+\\):\\([^:]*\\):" 1 2))

and if you don't want to have to preload compile.el from your .emacs file
(I personally hate it when I have to do that), you'l have to use something
like eval-after-load (a bit untidy) or to setq error-regexp-alist (really
ugly and likely to break in a future version of compile.el).

Hmm... there's room for improvement in compile.el.


        Stefan

Re: compilation-error-regexp-alist syntax problems

[Roy Smith]

In article 
<jwvk7342gu7.fsf-monnier+gnu.emacs.help@asado.iro.umontreal.ca>,
 Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> > Ah hah!  That's the problem.  It's not in the local version.
> > Next question, how do I get the local version to include it?
> 
> Looking at `compile-internal', it seems you'll have to do
> things differently.
> The simplest is:
> 
>    (require 'compile)
>    (add-to-list 'compilation-error-regexp-alist
>                 '("\\[javac\\] *\\(/[^:]+\\):\\([^:]*\\):" 1 2))
> 
> and if you don't want to have to preload compile.el from your .emacs file
> (I personally hate it when I have to do that), you'l have to use something
> like eval-after-load (a bit untidy) or to setq error-regexp-alist (really
> ugly and likely to break in a future version of compile.el).
> 
> Hmm... there's room for improvement in compile.el.
> 
> 
>         Stefan

Ah, I got it!

Once I got past the local/global problem, the next problem turned out to 
be that the regex apparantly must match the entire line (or at least 
anchored at the beginning).  Adding " *" to the front of the regex (to 
match the leading white space) did the trick.

I had never heard of looking-at before, that got me over that second 
hump.

Thanks for your most patient help!

The final working version is...

(require 'compile)
(add-to-list 'compilation-error-regexp-alist
             '(" *\\[javac\\] *\\(/[^:]+\\):\\([^:]*\\):" 1 2))

Re: compilation-error-regexp-alist syntax problems

[Kevin Rodgers]

Stefan Monnier wrote:

>>Ah hah!  That's the problem.  It's not in the local version.
>>Next question, how do I get the local version to include it?
>>
> 
> Looking at `compile-internal', it seems you'll have to do
> things differently.
> The simplest is:
> 
>    (require 'compile)
>    (add-to-list 'compilation-error-regexp-alist
>                 '("\\[javac\\] *\\(/[^:]+\\):\\([^:]*\\):" 1 2))
> 
> and if you don't want to have to preload compile.el from your .emacs file
> (I personally hate it when I have to do that), you'l have to use something
> like eval-after-load (a bit untidy) or to setq error-regexp-alist (really
> ugly and likely to break in a future version of compile.el).


What's untidy about eval-after-load?  My only complaint is that it's not a
macro, so we have to quote the FORM.


> Hmm... there's room for improvement in compile.el.

Could it be as simple as adding ;;;###autoload cookies to the 6 -regexp-alist
`defvar's?

-- 
Kevin Rodgers

Re: compilation-error-regexp-alist syntax problems

[Stefan Monnier]

> What's untidy about eval-after-load?  My only complaint is that it's not a
> macro, so we have to quote the FORM.

The macro is one such issue indeed:
Instead of (eval-after-load FOO '(progn BAR BAZ)), it should just be
(eval-after-load FOO BAR BAZ).
Do you have a suggestion for how to name such a new macro?

Another issue is that (eval-after-load "compile" FOO) will not run FOO
when loading "compile.elc" or "compile.el" or "/foo/bar/compile", but only
if you load "compile", even if those are all one and the same file.

In Emacs-CVS you can do (eval-after-load 'compile FOO) which will run FOO
right after executing (provide 'compile) which does adress the above
problem, but FOO will be run either before or after loading "compile",
depending on where the `provide' is located in the file (the coding
convention says to put it at the end, but several packages do not follow
the convention).

>> Hmm... there's room for improvement in compile.el.

> Could it be as simple as adding ;;;###autoload cookies to the 6 -regexp-alist
> `defvar's?

For this specific problem, it would help.  but it will still not fix
the `add-hook' code that Roy used originally.


        Stefan

Re: compilation-error-regexp-alist syntax problems

[Kevin Rodgers]

Stefan Monnier wrote:
 > > What's untidy about eval-after-load?  My only complaint is that it's
 > > not a macro, so we have to quote the FORM.
 >
 > The macro is one such issue indeed:
 > Instead of (eval-after-load FOO '(progn BAR BAZ)), it should just be
 > (eval-after-load FOO BAR BAZ).
 > Do you have a suggestion for how to name such a new macro?

How about `defloadforms' or `deflibforms'?

 > Another issue is that (eval-after-load "compile" FOO) will not run FOO
 > when loading "compile.elc" or "compile.el" or "/foo/bar/compile", but only
 > if you load "compile", even if those are all one and the same file.

It seems to work if you do (load-library "compile") or (require
'compile), so that issue doesn't bother me too much.  But it could
complicate things if you're trying to test a new version of "compile".

 > In Emacs-CVS you can do (eval-after-load 'compile FOO) which will run
 > FOO right after executing (provide 'compile) which does adress the
 > above problem, but FOO will be run either before or after loading
 > "compile", depending on where the `provide' is located in the file
 > (the coding convention says to put it at the end, but several packages
 > do not follow the convention).

Yes, because that coding convention seems odd to those of us who
memorized the Common Lisp mnemonic for managing packages: Put IN Seven
EXtremely Random USEr Interface COmmands.

I don't understand why it's better to evaluate the FORM immediately
after (provide FEATURE) or how that solves Roy's problem of augmenting a
list-valued variable defvar'ed in the FILE.  The advantage of late
evaluation (after the complete FILE is loaded) is that you can reference
the default value while computing its new value; the advantage of early
evaluation is that other default values can be computed based on this
variable's non-default value.  To me it's a wash that should probably be
decided in favor of allowing the user to access any variable's default
value, as when augmenting a list.

 >>Could it be as simple as adding ;;;###autoload cookies to the 6
 >>-regexp-alist `defvar's?
 >
 > For this specific problem, it would help.  but it will still not fix
 > the `add-hook' code that Roy used originally.

I thought it would result in those `defvar's being copied into
loaddefs.el, which would be dumped into the emacs executable, so they
could be safely referenced before the "compile" library was actually
loaded.  What am I misunderstanding?

-- 
Kevin Rodgers

Re: compilation-error-regexp-alist syntax problems

[Stefan Monnier]

> I don't understand why it's better to evaluate the FORM immediately
> after (provide FEATURE) or how that solves Roy's problem of augmenting a
> list-valued variable defvar'ed in the FILE.  The advantage of late

Assuming the `provide' is where the coding convention says it should be,
then evaluating FORM right after it means that it's evaluated when the file
has already been fully processed, just as Roy needs it.
And since it relies on the feature name rather than ht efile name, it does
not matter how you decided to load the file.

> I thought it would result in those `defvar's being copied into
> loaddefs.el, which would be dumped into the emacs executable, so they
> could be safely referenced before the "compile" library was actually
> loaded.  What am I misunderstanding?

Look at his add-hook code: it intuitively should work.  Yet, even with your
suggestion it won't work.  Your suggestion allows setting
compilation-error-regexp-alist directly, but it is of no use when the var
is set from the compilation-mode-hook.


        Stefan

Re: compilation-error-regexp-alist syntax problems

[Kevin Rodgers]

Stefan Monnier wrote:
 >>I don't understand why it's better to evaluate the FORM immediately
 >>after (provide FEATURE) or how that solves Roy's problem of augmenting a
 >>list-valued variable defvar'ed in the FILE.  The advantage of late
 >
 > Assuming the `provide' is where the coding convention says it should be,
 > then evaluating FORM right after it means that it's evaluated when the file
 > has already been fully processed, just as Roy needs it.
 > And since it relies on the feature name rather than ht efile name, it does
 > not matter how you decided to load the file.

But then does it only work for files that provide a feature identical
to (the base of) the file name?  The implementation of eval-after-load
shouldn't depend on users/ programmers adhering to all these various
conventions, IMHO.

 >>I thought it would result in those `defvar's being copied into
 >>loaddefs.el, which would be dumped into the emacs executable, so they
 >>could be safely referenced before the "compile" library was actually
 >>loaded.  What am I misunderstanding?
 >
 > Look at his add-hook code: it intuitively should work.  Yet, even with your
 > suggestion it won't work.  Your suggestion allows setting
 > compilation-error-regexp-alist directly, but it is of no use when the var
 > is set from the compilation-mode-hook.

Right, but that's because compile-internal overrides any changes to the
following variables that compilation-mode-hook might make to them:

	compilation-parse-errors-function
	compilation-error-message
	compilation-error-regexp-alist
	compilation-enter-directory-regexp-alist
	compilation-leave-directory-regexp-alist
	compilation-file-regexp-alist
	compilation-nomessage-regexp-alist
	compilation-arguments
	lazy-lock-defer-on-scrolling
	default-directory
	compilation-directory-stack

It looks like compilation-process-setup-function is the way to go:

| *Function to call to customize the compilation process.
| This functions is called immediately before the compilation process is
| started.  It can be used to set any variables or functions that are used
| while processing the output of the compilation process.

-- 
Kevin Rodgers

Re: compilation-error-regexp-alist syntax problems

[Stefan Monnier]

> But then does it only work for files that provide a feature identical
> to (the base of) the file name?

Not at all.  It doesn't care at all about filenames (or files for that
matter).  You give a FEATURE (i.e. a symbol) to `eval-after-load', and it is
matched to the FEATURE passed to `provide'.

> Right, but that's because compile-internal overrides any changes to the
> following variables that compilation-mode-hook might make to them:

Indeed.  I think that's what should be fixed.


        Stefan

Re: compilation-error-regexp-alist syntax problems

[Kai Grossjohann]

Roy Smith <roy@panix.com> writes:

> I'm running ant as my M-X compile command, and trying to get next-error
> to parse the output correctly.  The line I want to parse looks like:
>
>     [javac] fileName:lineNumber: message

Run "ant -emacs" instead of just "ant".  This will produce better
error messages.

Kai

Re: compilation-error-regexp-alist syntax problems

[Roy Smith]

In article <87n07x3of6.fsf@emptyhost.emptydomain.de>,
 Kai Grossjohann <kai@emptydomain.de> wrote:

> Roy Smith <roy@panix.com> writes:
> 
> > I'm running ant as my M-X compile command, and trying to get next-error
> > to parse the output correctly.  The line I want to parse looks like:
> >
> >     [javac] fileName:lineNumber: message
> 
> Run "ant -emacs" instead of just "ant".  This will produce better
> error messages.
> 
> Kai

Doh!  I wish I had known that a couple of days ago.

Oh well, at least now I've learned a bit more about compile mode, which 
I guess is useful in its own right :-)

Re: compilation-error-regexp-alist syntax problems

[Daniel Pfeiffer]

Hi,

Roy Smith <roy@panix.com> skribis:

> I'm running ant as my M-X compile command, and trying to get next-error
> to parse the output correctly.  The line I want to parse looks like:
> 
>     [javac] fileName:lineNumber: message
> 
> An example being:
> 
>     [javac]
>     /Users/roy/Muse/sandbox.tip/src/SnmpBugDb/data/scripts/test/DataBaseTes
>     tCase.java:20: unreported exception java.io.IOException; must be caught
>     or declared to be thrown

Recent versions of Emacs have copied a fantasy regexp, purporting to match
this, from the ant site.  Like a few other regexps in there, it doesnt' work
as
advertised.

Since the end of last year I have developed a new compilation mode for Emacs. 
It is more robust and matches a lot more than before -- including ant output. 
If you have a CVS Emacs only a few months old, get it from

http://dapfy.bei.t-online.de/compile.el

and to get an idea of what this will match

http://dapfy.bei.t-online.de/compilation.txt

best regards
Daniel