We don't want to push the inner class all the way to the
right of the open paren, or there would be no place to type it.
Of course, I can't really tell if that was what you intended
as the more aesthetically pleasing option, since SourceForge
conveniently crops off all spaces. Could you repost it here
with periods for spaces, so I can view it with a monospaced
font? (I'd like to see what you would recommend as an
alternative.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Argh... Can't SourceForge get anything right? They cropped
off one period from each line in the email that was sent
out, though it was displayed correctly (luckily in a
monospaced font) on the web page. Of course, I had a typo,
too-- I put one too many periods in the second line (new
LongNameListener).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I purposely put no formatting in my original post. Just
paste them both into DrJava, and the first code snippet
doesn't look so good and the second looks better. Currently
the beginning of the second line ("new LongNameListiner() {"
in your example) is aligned far, far to the right, and the
rest is not aligned so far. I don't have a suggestion to
fix this that doesn't involve moving everything to the
right. The question then becomes where to line up a close
parenthesis on its own line at the end. emacs lines up
close parenthesis with the open parenthesis but otherwise
indents like us. emacs example:
This may seem to make no sense, but consider the following
(non)indentation by drjava:
method(
);
or:
method(int VERY_LONG_ARGUMENT_NAME
.........);
Here making the close paren line up with the open paren
seems a good idea. So in conclusion: where does a close
paren on its own line belong? And should we even care?
Finally: how does this attempt to prevent excessive
indentation apply to specifying members of an array in curly
braces (see 312 Bug Fixes task# 70906)? Should we be
careful to stop indenting all the way right if someone wants
to specify an anonymous class as part of an array?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=429731
Actually, I believe the indentation as DrJava performs it
was intentional. Consider a similar case:
getMyObject().addNewModelListener(arg1,
...................................new LongNameListener() {
..public void respond() {
....foo();
..}
});
We don't want to push the inner class all the way to the
right of the open paren, or there would be no place to type it.
Of course, I can't really tell if that was what you intended
as the more aesthetically pleasing option, since SourceForge
conveniently crops off all spaces. Could you repost it here
with periods for spaces, so I can view it with a monospaced
font? (I'd like to see what you would recommend as an
alternative.)
Logged In: YES
user_id=429731
Argh... Can't SourceForge get anything right? They cropped
off one period from each line in the email that was sent
out, though it was displayed correctly (luckily in a
monospaced font) on the web page. Of course, I had a typo,
too-- I put one too many periods in the second line (new
LongNameListener).
Logged In: YES
user_id=691516
I purposely put no formatting in my original post. Just
paste them both into DrJava, and the first code snippet
doesn't look so good and the second looks better. Currently
the beginning of the second line ("new LongNameListiner() {"
in your example) is aligned far, far to the right, and the
rest is not aligned so far. I don't have a suggestion to
fix this that doesn't involve moving everything to the
right. The question then becomes where to line up a close
parenthesis on its own line at the end. emacs lines up
close parenthesis with the open parenthesis but otherwise
indents like us. emacs example:
getMyObject().addNewModelListener(arg1,
..................................new LongNameListener() {
..public void respond() {
...foo();
.}
}
..................................);
This may seem to make no sense, but consider the following
(non)indentation by drjava:
method(
);
or:
method(int VERY_LONG_ARGUMENT_NAME
.........);
Here making the close paren line up with the open paren
seems a good idea. So in conclusion: where does a close
paren on its own line belong? And should we even care?
Finally: how does this attempt to prevent excessive
indentation apply to specifying members of an array in curly
braces (see 312 Bug Fixes task# 70906)? Should we be
careful to stop indenting all the way right if someone wants
to specify an anonymous class as part of an array?
Logged In: YES
user_id=429731
Raising the priority on this, since it is being addressed as
part of Task 70906 ("Indent Bugs").
Logged In: YES
user_id=429731
Updating the title to make it clear it is an indent bug, and
setting its priority back, since we're moving onto some
other projects in 312.
IndentBug Sample
Corky found another example of incorrect indentation of an anonymous inner class in a method call. Sample is attached as file.