java line termination

java line termination

[Tom Tromey]

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English, because the Emacs maintainers do not have
translators to read other languages for them.

Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing list,
and to the gnu.emacs.bug news group.

In GNU Emacs 21.2.1 (i386-redhat-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2002-04-08 on porky.devel.redhat.com
configured using `configure  i386-redhat-linux --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --with-gcc --with-pop --with-sound'
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.iso885915
  locale-coding-system: iso-latin-9
  default-enable-multibyte-characters: nil

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:


Java has its own rules for what constitutes a line terminator.

A bare \r is one, as is a bare \n; but the \r\n sequence is also
considered a single terminator.

I've run across Java source code which uses a mix of different line
terminators in a single file.  While ugly, there's not much I can do
about it.

If I compile code like this with gcj, and then use gdb to debug it, I
find that the debug arrow will be misplaced, because Emacs and gcj
disagree about the current line number.  Similarly, M-x next-error
will sometimes jump to the wrong line, as gcj reports line numbers
according to Java rules, but Emacs interprets them according to its
own rules.

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



Recent input:
l i k e SPC t h e r e ' s SPC m o r e SPC f o r SPC 
u s SPC t o SPC d o SPC h e r e SPC : - ( C-u C-b C-k 
l <backspace> , SPC b l e a h . C-p C-k C-e C-f C-f 
C-n C-f C-n C-f C-v C-c C-c M-v z C-c b C-v C-s j a 
v a C-w C-w C-w C-w C-s C-l C-s C-s C-s C-s C-s C-s 
C-s C-a M-x r e p o r t - e m <tab> <return>

Recent messages:
Saving file /home/tromey/.newsrc.eld...
Wrote /home/tromey/.newsrc.eld
Saving /home/tromey/.newsrc.eld...done
Mark set
set-mark-command: No mark set in this buffer [2 times]
Mark set [4 times]
Auto-saving...done
Sending...done

Mark saved where search started [2 times]

Tom

Re: java line termination

[Richard Stallman]

    If I compile code like this with gcj, and then use gdb to debug it, I
    find that the debug arrow will be misplaced, because Emacs and gcj
    disagree about the current line number.  Similarly, M-x next-error
    will sometimes jump to the wrong line, as gcj reports line numbers
    according to Java rules, but Emacs interprets them according to its
    own rules.

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

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

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

Fixing GCJ would be much cleaner, and definitely more in the GNU
tradition.  We do not follow standards slavishly; we follow them
to the extent it is useful for users that we do so.  So the question
is, would this change in GCJ have any downside, for the users?

Re: java line termination

[Tom Tromey]

>>>>> "rms" == Richard Stallman <rms@gnu.org> 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

Re: java line termination

[Richard Stallman]

    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'.

Right.  And this or another option could control how to generate the
line numbers for debugging.  We could make the GNU Java debugger work
consistently with ordinary GNU line numbering, when and if we have a
GNU Java debugger.

    What if Emacs could recognize inconsistent termination and make it
    consistent somehow?

This could conceivably be another kind of EOL conversion, say "Java"
conversion.  It could treat every stray CR, every stray LF, and every
CRLF, as a line end.  That might be a lot of work, but I don't know
for certain.

But this would lose the information about which kind of line
termination was used in each line.  Saving the file would result in
one that had consistent line termination.

If that isn't a problem, this solution might work.

Re: java line termination

[Tom Tromey]

>>>>> "rms" == Richard Stallman <rms@gnu.org> writes:

rms> This could conceivably be another kind of EOL conversion, say "Java"
rms> conversion.  It could treat every stray CR, every stray LF, and every
rms> CRLF, as a line end.  That might be a lot of work, but I don't know
rms> for certain.

rms> But this would lose the information about which kind of line
rms> termination was used in each line.  Saving the file would result in
rms> one that had consistent line termination.

Would merely visiting such a file cause the buffer to appear to be
modified?  If not, then I think this approach would work fine.

Tom

Re: java line termination

[Richard Stallman]

    rms> But this would lose the information about which kind of line
    rms> termination was used in each line.  Saving the file would result in
    rms> one that had consistent line termination.

    Would merely visiting such a file cause the buffer to appear to be
    modified?  If not, then I think this approach would work fine.

The buffer will not be marked as modified right after you visit it;
but conversion will have lost information, so if you proceed to edit
the buffer and save it, the line breaks will be different.

Is that really ok?

Handa, how hard is this to do?  The idea is a new kind of EOL
conversion that treats CRLF, CR and LF as line terminators and
converts them all to newlines.  We would then want to use this
by default for all Java programs.

Re: java line termination

[Tom Tromey]

>>>>> "rms" == Richard Stallman <rms@gnu.org> writes:

rms> The buffer will not be marked as modified right after you visit it;
rms> but conversion will have lost information, so if you proceed to edit
rms> the buffer and save it, the line breaks will be different.

rms> Is that really ok?

It isn't ideal, but I think it is acceptable.
I think mixed-termination buffers end up that way only by mistake anyway.
If I'm editing there, I'll probably want to fix it, and anyway I can
justify the change.

Tom