Community
Participate
Working Groups
When using the new "format edited lines" option, excess new lines are not removed. I used the formatter settings to ask for no more than 1 newline between methods. This works great when using the "format all lines" option. However, with "format edited lines" these lines are not removed.
Sure. As you probably didn't touch those lines.
Actually, I did. I was writing new methods. I'm working on Mac OS X, BTW, not sure it matters. Anyway, it doesn't work for me. You can choose to do whatever you want with it.
>Anyway, it doesn't work for me. You can choose to do whatever you want with it. Please... If you read again your initial comment, then you see this is not clear. Also, there is no information about which build you are using i.e. maybe this bug has been fixed already. So: if you can provide the build ID and a small example which does not work for you then we can take a closer look.
I'm using the 3.4RC3, that's Build id: I20080530-1730. I'll give you at lease one example of the problem. My example could be argued, however, I believe I encountered this in other cases as well. I wrote the following two methods: void foo() { } void bar() { } Note that I had two blank lines between them. Saved. The blank line is reduced to one line. Next, I started editing, and added a blank line. Saved. the blank line is not removed. I edited both methods, "touching" each of the lines (including the blank lines) with spaces, saved. The blank lines are not removed. The only case where the blank lines are removed is when the methods are written from scratch.
(In reply to comment #4) > I'm using the 3.4RC3, that's Build id: I20080530-1730. > The only case where the blank lines are removed is when the methods are written > from scratch. I can not confirm that: It sometimes works and sometimes not. Most of the time it does work if you change exactly one line between the methods, but sometimes it doesn't either. I can not see a pattern, need to investigate. See also bug 237592
Created attachment 106837 [details] test class In given test class and eclipse build in code formatter settings: 1. Select [59 + 3] 2. Ctrl+Shift+F Is: nothing 3. Select [61 + 1] 4. Ctrl+Shift+F Is: extra line is removed IMHO it should be exactly the other way around, at least when selecting [59 + 3] then the extra line should also be removed. See screen shot.
Created attachment 106840 [details] screen shot
Moving to jdt/core, they own the code formatter.
Still the same problem with regions adapting... Fix for bug 234583 should also fix this one => set as duplicate *** This bug has been marked as a duplicate of bug 234583 ***
Finally this is not a duplicate of bug 234583... The problem comes from the given region. In comment 6 step 3, the region is [61+1] which is only the tabulation character. As the formatter should not format outside the given region, there's nothing it can do to remove the extra line. If the region would include the new lines characters (\r\n assuming its a windows format file), hence was [61+3], then the formatter could remove the extra line...
As fix for bug 234583 has been released in HEAD, this bug can be moved to JDT/Text component in order to enlarge the provided region to include the line character(s) to give the formatter a chance to remove the inserted line...
(In reply to comment #10) > Finally this is not a duplicate of bug 234583... > > The problem comes from the given region. In comment 6 step 3, the region is > [61+1] which is only the tabulation character. As the formatter should not > format outside the given region, there's nothing it can do to remove the extra > line. > > If the region would include the new lines characters (\r\n assuming its a > windows format file), hence was [61+3], then the formatter could remove the > extra line... > Please, Frederic, read my comment #6: If selection is [61+1] the extra line _is_ removed, if the selection includes the new line then the extra line is _not_ removed: > IMHO it should be exactly the other way around
Moving back to core for closer look. BTW: The last quote from comment 12 was Benno, quoting himself from comment 6.
(In reply to comment #12 and comment #13) Sorry, It seems I read the steps in the opposite way :-( So, the described behavior does no longer occurred after fix for bug 243584 was released. However, there's still a little problem with step 4 when selection is [61+1], the formatter replace the selected space with a tabulation. It should better remove the selected space instead...
Created attachment 111387 [details] Proposed patch This patch fixes the last problem with [61+1] selection...
Released for 3.5M2
Verified for 3.5M2 using I20080914-2000
