help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

emacs cygwin compile.el next-error fails with Ant


From: Mark Evenson
Subject: emacs cygwin compile.el next-error fails with Ant
Date: 23 Jul 2003 03:59:27 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3

Using the cygwin port of of GNU Emacs 21.2.1 (running on a Windows 2000
pre-SP4host ), I have a bad interaction between Ant 1.5.3-1 and next-error
of compile mode that results in Emacs being unable to "automatically" visit
the source of errors.

To wit:

With M-x compile invoked with "ant -emacs" one gets errors like:

----------------------------------------------------------------------
cd ~/work/cs9/
ant -find build.xml
Searching for build.xml ...
Buildfile: C:\cygwin\home\evenson\work\cs9\build.xml

classes:

compile:
Compiling 2 source files to C:\cygwin\home\evenson\work\cs9\classes
C:\cygwin\home\evenson\work\cs9\src\org\unodc\data\sql\BaseQueryCommand.java:21:
';' expected
  protected BaseQueryCommand(String databaseURL, String username, String
  password)
                                                                                
  ^
C:\cygwin\home\evenson\work\cs9\src\org\unodc\data\sql\BaseQueryCommand.java:40:
'class' or 'interface' expected
}
^
C:\cygwin\home\evenson\work\cs9\src\org\unodc\data\sql\BaseQueryCommand.java:41:
'class' or 'interface' expected
^
C:\cygwin\home\evenson\work\cs9\src\org\unodc\data\sql\GetTable.java:17:
illegal start of expression
  }
[...]
----------------------------------------------------------------------

When 'next-error' is invoked, the appropiate string
(i.e.
"C:\cygwin\home\evenson\work\cs9\src\org\unodc\data\sql\BaseQueryCommand.java")
is correctly parsed by the regexp within compile.el, but it is not a valid
argument for "find-file" and its ilk, as the cygwin environment provides
POSIX emulation of filesystem mountpoints (i.e. forward slashes, mount
points syntactically grafted to root).

cygwin has a commandline utility in "cygpath" that will translate back and
forth from these conventions.  So no problem, I thought, as the 
compile.el variable "compilation-parse-errors-filename-function" will make
a transformational pass, so I whipped up a function like:

      (defun filepath-transform-win32-to-cygwin (filepath)
             (shell-command-to-string (concat "cygpath -u " filepath)))

and then 

       (setq compilation-parse-errors-filename-function 
             'filepath-transform-win32-to-cygwin)

But now the default choice that pops up in the minibuffer is the filepath
stripped of all filepath separators
("C:cygwinhomeevensonworkcs9srcorgunodcdatasqlBaseQueryCommand.java").

This is where I have to stop hacking Emacs and go back to work for a while,
so would appreciate advice on how to proceed further if anyone can offer
it, as the use of backslash "\" in Emacs string types has always confused
my meagre elisp skills.

-- 
Mark Evenson <evenson@panix.com>

"A screaming comes across the sky.  It has happened before, but there is
nothing to compare to it now."


reply via email to

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