[Help Needed] Implement provider for sticky scrolling in JAVA/JDT

[Christopher-Hermann]

What it does

The current sticky scrolling functionality is based solely on indentation. This can cause issues when the source code is formatted in unexpected ways. To address this, an extension point for providing language-specific sticky lines has been introduced in the following pull request: eclipse-platform/eclipse.platform.ui#2398.

This change represents the first proof-of-concept implementation for sticky lines in Java/JDT. As I lack experience in JDT development, the proposed approach for calculating sticky lines in Java may not be optimal.
I would greatly appreciate assistance from the community in identifying a more effective method for calculating sticky lines.

Fixes:
eclipse-platform/eclipse.platform.ui#1950
eclipse-platform/eclipse.platform.ui#2128
eclipse-platform/eclipse.platform.ui#2338

How to test

1. Check out the PR from [StickyScrolling] Add extension point for sticky lines provider eclipse-platform/eclipse.platform.ui#2398. and open plugin org.eclipse.ui.editors
2. Enable the Sticky Scrolling Feature via Preferences > General > Editors > Text Editors > Enable Sticky Scrolling
3. Open the class EnumMap, scroll to line 775 (method writeObject)

With proper Sticky Lines calculation:

With the Default Sticky Lines calculation based on indentation:

[BeckerWdf]

Is JDT interested in such a feature?
@jukzi: Could you ask one of the JDT committers to have a look at this?

[jukzi]

what kind of help do you need? build currently fails because it can not find the internal(!) API
org.eclipse.ui.internal.texteditor.stickyscroll.IStickyLine
referenced as
org.eclipse.ui.texteditor.stickyscroll.IStickyLine

[BeckerWdf]

@Christopher-Hermann asks for this:

This change represents the first proof-of-concept implementation for sticky lines in Java/JDT. As I lack experience in JDT development, the proposed approach for calculating sticky lines in Java may not be optimal.
I would greatly appreciate assistance from the community in identifying a more effective method for calculating sticky lines.

Could you or some of your JDT co-committers help him?

[jukzi]

Could you or some of your JDT co-committers help him?

I lack the skill for that. Maybe @jjohnstn could help?

[BeckerWdf]

ping @jjohnstn
Can you help here?

[jjohnstn]

@BeckerWdf I'll take a look

[jjohnstn]

Hi. I agree that indent level is insufficient information for many Java files. However, using the JavaModel is also insufficient. As you have found, you can only show Types and Methods which is less functionality than currently exists for a normally indented piece of source code (e.g. if statements,else blocks, for statements, etc... are shown).

What you need to do is parse the compilation unit and get an AST. With the AST, you can get the detail needed. For example, you may find the parent of the current statement is a block but your logic can skip over blocs and find the next parent which could be an if statement, for statement, etc... that you can choose to display. The indentation doesn't matter.

There is code in Checks.Java:

	public static CompilationUnit convertICUtoCU(ICompilationUnit compilationUnit) {
		ASTParser parser= ASTParser.newParser(IASTSharedValues.SHARED_AST_LEVEL);
		parser.setKind(ASTParser.K_COMPILATION_UNIT);
		parser.setSource(compilationUnit);
		parser.setResolveBindings(true);

		return (CompilationUnit) parser.createAST(null);
	}

as an example or parsing an ICompilationUnit to get a CompilationUnit. I do not believe you need to resolve bindings so the set call in the example should be false. From there you can find any ASTNode from its position using NodeFinder or use a custom ASTVisitor. You can define what elements you want to show (e.g. if statement, else clause, etc...) vs ignore (e.g. block, variable declaration).