Jon Schewe writes: > On Tue, 2004-10-12 at 11:00, Paul Kinnucan wrote: > > The doc says this variable should only be set if you have a Microsoft > > Windows GUI app that does standard I/O (GUI Windows apps typically do > > not do standard I/O). It would seem to me that this variable should > > not be set to t unconditionally as the JDEE currently does. There > > should be some JDEE variable that would allow you to specify whether > > the app you are about to launch is an app of the appropriate type. At > The app here is defined as java or javaw, not the Java application being > written, so I suspect the current JDEE behavior is correct. > > > any rate, the doc also says that this variable has no effect on > > Unix. Despite this, the facts that this variable affects process I/O > > under some circumstances and that the variable is only used by XEmacs > > seem to correlate strongly with the problem you are having. So I would > > suggest that you comment out the binding of this variable in the > > save-w32-show-window macro in jde-run.el, recompile jde-run.el if > > necessary, and see if that makes a difference. > > I tried that and it doesn't help. I even commented out the call to the > macro and evaluated the method again and still the same behavior. > > I tried adding 2>&1 onto the end of my execution line and that doesn't > seem to help either.
I'm grasping at straws here but you could try adding (setq process-connection-type nil) to your .emacs file. This variable is set to t by default on XEmacs. If I understand the doc correctly, this tells XEmacs to use pseudo terminal (pty) commands to connect to the external process. I believe Java uses pipes for interprocess communications. Thus if XEmacs is using pty and Java is expecting pipes, there could be a problem. Paul > > > > ________________________________________________________________________ > Your mouse has moved. > Windows must restart for change to take effect. > Reboot now? [OK] > http://web-unix.htc.honeywell.com/people/jschewe [Honeywell Intranet > Only] > *My views may not represent those of my employers >