Fix folding of 2 consecutive methods

[jakub-suliga]

If the second method starts on the same line where the first one ends, there will still be two foldings. (I accidentally set includeLastLine to true a second time, which caused the issue).

Additionally, I have separated the tests: FoldingTest verifies the old behavior, while FoldingTestNew tests my feature (#1562).

Fixes #1992

[danthe1st]

While you are at it, I noticed that local classes (defined in methods) are folded with the old folding but not with your new folding.
In the following example, Inner2 doesn't seem to be folded if your new folding is activated.

class Outer {
	void a() {
		class Inner2{
			
		}
	}
}

Is this intentional?

Apart from that, I want to inform you that there is also the idea of using folding annotations for sticky scrolling. See #1851 (comment) and eclipse-platform/eclipse.platform.ui#2756 (comment) for details on that. I just want to make sure you know about that discussion.

Given that (at least if this is done), it may even be worth considering to add a folding annotatation for Outer but I guess this may need more discussion.

[danthe1st]

Another change that I think is probably intentional (in contrast to the previous one) is that multiline comments are folded within methods:

public class Test {
	void a() {
		/*
		 * This multiline comment is folded with the AST-based folding but not the old one.
		 */
	}
}

To be honest, I would probably consider that to be a good thing.

(These are part of one of the tests I'm using in my PR which is why I noticed that since I'm running mostly the same tests on both folding strategies.)

I am pointing this out to ensure that all changes you made are intentional.

[jakub-suliga]

that multiline comments are folded within methods:

This is intentional, I want that every comment can be folded.

[jakub-suliga]

While you are at it, I noticed that local classes (defined in methods) are folded with the old folding but not with your new folding.
In the following example, Inner2 doesn't seem to be folded if your new folding is activated.

Fixed and added a test case for it.

Given that (at least if this is done), it may even be worth considering to add a folding annotatation for Outer but I guess this may need more discussion.

The plan is for outer to also receive a folding annotation. When I initially tried to implement this, I encountered some issues and decided to put it on hold at the time.

[jakub-suliga]

@fedejeanne @jjohnstn could you look over the code?

[fedejeanne]

I haven't looked deep into the code but I'd like for you to please:

• Only solve 1 issue in this PR: the folding of 2 consecutive methods
• Create another PR to rename/move the tests and split testing the "old" folding and the "new" folding (if even necessary).

A hint for the other PR (the one about the tests): you don't need to create a new test class, you can parameterize the tests to use the "old" and/or the "new" folding: the deciding part is probably store.setValue(PreferenceConstants.EDITOR_NEW_FOLDING_ENABLED, x); with x being the parameter for the tests. With that, you can simply write all the tests, skip some if necessary (i.e. if the "old" folding doesn't work for a given structure) and adapt the assertions. That way you will probably avoid having duplicated test code (e.g. testinnerClassinMethod) and you'll make sure that no one forgets to add tests for any of the foldings in the future since all the test methods are in the same class.

[fedejeanne]

Hopefully, you will not need another class and you can parameterize FoldingTest (see my comment in the review). In any case, the name FoldingNewTest would have been better. But please let's move this discussion to another PR.