Re: java line termination

[Tom Tromey]

>>>>> "rms" == Richard Stallman <address@hidden> writes:

rms> Why does GCJ follow the Java convention for the line number
rms> in its error messages?  I see no reason to do that.  Does it
rms> have anything to do with correct execution of the Java program?
rms> If this were changed, in what sense would that be a problem?

I think the gcj issue is a red herring.  I'll try to respond anyway,
though, and come back to the other stuff.

Changing gcj here probably wouldn't affect correct execution of the
code.  I can't think of a situation where it would.  However, it would
cause us to fail some more tests in Jacks (Jacks is a free software
test suite for Java compilers).  Though I suppose we could revert to
java-style line termination with `-pedantic'.

It would affect the bytecode generated by `gcj -g -C'.  This means
that other java debuggers would display things incorrectly, stack
traces in java interpreters would have the wrong line numbers (at
least to users who aren't using Emacs), etc.

>     I think in java-mode Emacs ought to respect Java's notion of line
>     termination.

rms> That is probably impossible because the buffer contents have already
rms> been subject to EOL conversion.  If you turn this off, Emacs will
rms> display \r as ^M, which will be rather annoying.  Emacs has many
rms> line-counting features and you would have to change them all.
rms> It is not feasible.

What's going on here is that I have some files with inconsistent line
termination.  Right now if I have a file with consistent \r\n
termination, Emacs will mark it as `DOS' and display things, count
line numbers, etc, in the way I would expect.

What if Emacs could recognize inconsistent termination and make it
consistent somehow?  For instance it could mark every "weird"
terminator, convert the whole buffer to \n, and then revert each
terminator to its original state on saving.  New terminators could
take whatever form is convenient; since the file is inconsistent to
start with this wouldn't matter.

Perhaps this transformation could only be applied to java files, or in
response to some flag setting.


I haven't used jdb yet; this is an instance of gud-mode that runs jdb
(a Java debugger) underneath.  How does jdb deal with files like this?
What if the files were compiled with a non-gcj Java compiler?  What
about using M-x next-error when the java code is not compiled by gcj?
Another failure mode is if we compile the bytecode output of some
other compiler with gcj; in this case we can't rewrite the line
numbers.  In fact, it was this exact scenario where I first noticed
the problem.

Tom