This is exactly the same issue/question I raised earlier on, when one is using e.g. ant to run the java application - then the trace is in the standard compilation buffer (and thus the run-etrace stuff is not activated properly).......
I looked high and low for a possibility to activate the etrace stuff in any compilation buffer and the only solution I could find was the following: (global-set-key [f8] 'jde-run-etrace-show-at-point) (global-set-key [S-f8] 'jde-run-etrace-next) (global-set-key [C-f8] 'jde-run-etrace-prev) Which binds the f8 key to do something usefull - if the current buffer contains some java stack trace. Hope it can help (I would prefer the options which are available for running a program also is availble when building/compiling - would make a life much easier :) /max "Paul Kinnucan" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]... > Robert Mecklenburg writes: > > When I get a java stack trace in a compilation buffer I would like to > > be able to use next-error to move through the stack trace looking at > > each line and loading the source files. To the best of my knowledge > > this doesn't work in 21.2.1 OOTB (I'm using the "standard" NT > > pre-compiled binary). > > > > Before I go implementing this does anyone know of existing code to do > > it? > > > > - I've found a file, jde-stack.el by Kevin Burton (and Phillip Lord) > > but it is more of a point and click implementation. You mouse click > > on the line you want and it takes you there. It has no hooks to > > compilation-mode or next-error. This also performs a pop-to-buffer > > so it fails on a dedicated *compilation* window (like you get with > > special-display-buffer-names). > > Actually, this has been reimplemented in JDE 2.2.9beta as run-time > exception tracing (jde-run-etrace in jde-run.el). The reimplemented > version is greatly simplified and does not rely on pop-to-buffer. > > I'm curious as to why you get exceptions when compiling code. If that > is the case, it seems to me the exceptions would be in the javac > compiler code not in your code. Or are you talking about using the > Emacs compile command to run a makefile that executes an application > that then generates exceptions? If so, why can't you use the JDE > run command to run your application and use the JDE trace commands > to trace the exception stack that an exception generates in > the run buffer? > > - Paul > > > > > - There is also qflib at http://www.qfs.de/en/elisp/index.html which > > contains a stack trace parser, but it also is not implemented as a > > hook to compilation-mode. Rather, like jde-stack, you place your > > cursor on a stack trace line and invoke it to find the function. It > > also performs a pop-to-buffer. > > > > - I tried setting compilation-error-regexp-alist like this: > > > > (setq compilation-error-regexp-alist > > (append compilation-error-regexp-alist > > (list '("\\bat \\(com\\.cimsoft.*\\)(\\([^:]+\\):\\([0-9]+\\))" 2 3)))) > > > > But compilation-mode cannot find the file (although once you tell it > > where the file it is, it takes you to the proper line). I have been > > unable to discover how to let compilation-mode discover the file > > location itself. > > > > - A really good implementation of next-error would also be able to > > garb source files out of source jars (such as the jdk1.3.1/src.jar > > file). But right now that's definitely icing on the cake. So as a > > fall back it would be nice for the function to skip stack trace > > lines for which source code is not available. > > > > Obviously, I have many possibilities. I'd rather not come up with yet > > another custom hack, rather I'd like to do the Right Thing (tm) wrt > > compilation-mode. > > > > Thoughts? > > -- > > Robert > > > > >
