Faulty/Undesired CodeCompletion behaviour #2620 by angelickite · Pull Request #3350 · eclipse-jdt/eclipse.jdt.core

angelickite · 2024-11-26T11:27:33Z

What it does

Add cursor awareness to various auto-completion situations.

Completions for CompletionOnMessageSendName as well as for QualifiedNameReference did not take the cursor position into consideration, leading to various downstream issues like failing to complete at all, not properly overwriting a source range or overwriting too eagerly.

fixes #2620

How to test

I've included some tests. A thorough description can be found in #2620.

Author checklist

I have thoroughly tested my changes
The change is following the coding conventions
I have signed the Eclipse Contributor Agreement (ECA)

jukzi · 2024-11-26T13:21:55Z

 			boolean insideTypeAnnotation, boolean isInsideAnnotationAttribute, InvocationSite site, char[][] tokens, long[] sourcePositions)
 	{
-		long completionPosition = sourcePositions[sourcePositions.length - 1];
+		// we take the cursor location into consideration.


I am not qualified to make a in-depth review, but i can help with some formals. it would help here if you start the code example with "Example:" otherwise it looks like out commented code

jukzi · 2024-11-26T13:22:14Z

+		// in the above example, bestPosition will match against the cursor after 'ch', i.e. sourcePositions[1].
+		// (sourcePositions[0] points to 'node', sourcePositions[4] to 'parent')
+		long bestPosition;
+		{


why start a codeblock here?

jukzi · 2024-11-26T13:23:02Z

+		long bestPosition;
+		{
+			bestPosition = -1L;
+			for (int i = 0; i < sourcePositions.length; i++) {


You can use a for-each loop here? would be easier to read.

jukzi · 2024-11-26T13:24:27Z

+				int end = (int) (p);
+				{ // in specific cases like "node.|.child" the start might be larger than the end (see GH-2620)
+					if (start > end) {
+						int tmp = start;


if this code should swap start and end, you could add it as comment.

jukzi · 2024-11-26T13:26:02Z

+			}
+		}
+		if (bestPosition == -1L) {
+			// fallback to the previous behaviour, just in case.


In future it will not be clear what "previous" refers to. Please instead describe what the previous behavior was.

jukzi · 2024-11-26T13:29:33Z

+		this(selector, start, end, setup -> {/* use defaults */});
+	}
+
+	public CompletionOnMessageSendName(char[] selector, int start, int end, Consumer<CompletionOnMessageSendName> setup) {


instead of using a Consumer for setup it would be easier to understand and maintain if you directly pass the initial values to the constructor. probably "cursorIsToTheLeftOfTheLParen" misses a "t" at the end and could be final.

In order to unblock the change I'm applying some of these suggestions, but here's one correction: LParen is correct compiler lingo to refer to '(' (short for left parenthesis), nothing to do with parents :)

Completions for CompletionOnMessageSendName as well as for QualifiedNameReference did not take the cursor position into consideration, leading to various downstream issues like failing to complete at all, not properly overwriting a source range or overwriting too eagerly. fixes eclipse-jdt#2620

Changes during review: + revert overhead that was used just to set one addition boolean field + code simplification also in CompletionEngine Tests: + make expected relevance explicit in terms of individual constants + two more tests to observe incremental differences 1a: when cursor is immediately after '(' 1b: immediately before '(' when the selected method has parameters fixes eclipse-jdt#2620

stephan-herrmann · 2025-01-18T15:07:51Z

Trying to unblock this issue I ...

rebased the existing commit on HEAD (without any changes)
added a commit of code simplifications (also considering @jukzi's comments) and additional tests.

One more observations, and one remaining task:

(1) We should call out that the change in CompletionTest.testCamelCaseLocalVariable1() fixed a test bug, which would affect proposals of Object.clone() and Object.finalize() in unrelated tests, if run after this one.

(2) I'm seeing a regression when trying the following in the IDE:

public class GH2620_1 {
	public static void main (String[] args) {
		int j = 1;
		Test local;
		if (true) { // the if-statement is crucial for this test.
			/*x*/local.ref.test|();
		}
	}
	public static class Test {
		public Test ref;
		public static void test(int i) {}
	}
}

Cursor location is indicated by |.

Old behavior: argument j is proposed.
New behavior: argument j is proposed only when completion operates in 'insert' mode. When selecting 'overwrite' no argument is proposed.

@angelickite can you find out, if this is a bug in JDT/UI, or can/should be fixed here?

angelickite · 2025-01-18T22:31:34Z

@stephan-herrmann Are we on the same page that this regression is foremost a side effect of the new approach? What I mean by that:

The new approach is generally well behaved
Specifically when the completion is operating on any part names (i.e.. local, ref and test in the above example), then the completion should only affect these parts names.
If the method name is the target, only the method name should be operated on and the argument list not be touched, i.e existing arguments should remain as they are. (e.g. System.out.print|("Hello") -> System.out.println("Hello"))

So the regression then manifests itself in the case where we have an empty argument list and can potentially safely modify the argument list too as a bonus feature as there is "nothing to break"?

If this is the situation you refer to as the regression, looking back I did see this case appear but never gave it any attention or thought. Reason being that the completion behaviour around arguments always felt janky anyways as well as it not negatively impacting my workflow.

If this feature is truly highly important, I will take a look where it originates and whether there is a sensible solution.

Lastly, I personally would prefer this sidegrade every time over having the old behaviour back.

stephan-herrmann · 2025-01-18T22:47:19Z

The new approach is generally well behaved

I generally agree.

So the regression then manifests itself in the case where we have an empty argument list and can potentially safely modify the argument list too as a bonus feature as there is "nothing to break"?

I didn't investigate the exact conditions under which arguments are proposed, perhaps my scenario is the only one, perhaps the feature applies much more broadly. I didn't test.

If this is the situation you refer to as the regression, looking back I did see this case appear but never gave it any attention or thought. Reason being that the completion behaviour around arguments always felt janky anyways as well as it not negatively impacting my workflow.

I agree that the behaviour around arguments has room for improvement. But that even more motivates me to be careful that we don't break behaviour that exists at present and may be very important to some users. A somewhat messy situation is no excuse for piling up more inconsistencies - and as I said the current state in this PR is inconsistent between insertion / overwrite modes.

For me personally, support for arguments in calls to methods with long parameter lists is actually very relevant.

If this feature is truly highly important, I will take a look where it originates and whether there is a sensible solution.

I'd appreciate. It would already help if we only find out if the problem is in jdt.core or jdt.ui.

Lastly, I personally would prefer this sidegrade every time over having the old behaviour back.

I wouldn't wont to judge one user's needs against those of another :)

angelickite · 2025-01-19T14:10:07Z

The regression is here: https://github.com/angelickite/eclipse.jdt.core/blob/aa0c66d368586cdc30c18511f260519c80c59ff7/org.eclipse.jdt.core/codeassist/org/eclipse/jdt/internal/codeassist/CompletionEngine.java#L3263-L3270

So it stems directly from the new behaviour where "cursor to left of lparen" is given special consideration.

Something like this just might do the trick (limited testing):

// we take the cursor location into consideration
if (messageSend.cursorIsToTheLeftOfTheLParen && messageSend.arguments != null) {
  setSourceAndTokenRange(messageSend.sourceStart, messageSend.sourceEnd);
else {
  setTokenRange(messageSend.sourceStart, messageSend.sourceEnd);
  if (messageSend.statementEnd > messageSend.sourceStart)
    setSourceRange(messageSend.sourceStart, messageSend.statementEnd);
}

(note the added messageSend.arguments != null)

stephan-herrmann · 2025-08-09T15:09:44Z

@angelickite are you interested in taking this to completion?

the L-Paren checks were redundant as `CompletionOnMessageSendName` already guarantees the cursor to be in a "good position".

angelickite · 2025-10-04T17:30:08Z

@stephan-herrmann Should be good to go. The various holes in codecompletion go quite deep... so I've tried to find a balance between "keeping sanity", "recovering lost value", "maintaining the status quo" and "taking a step towards a better future".

angelickite · 2025-12-22T16:39:46Z

@stephan-herrmann Another ping.

angelickite mentioned this pull request Nov 26, 2024

[GH-2620] consider the cursor location in completions #3345

Closed

3 tasks

jukzi reviewed Nov 26, 2024

View reviewed changes

angelickite and others added 2 commits January 18, 2025 14:38

stephan-herrmann force-pushed the gh2620-2 branch from 0dc2dc8 to aa0c66d Compare January 18, 2025 14:55

stephan-herrmann added this to the 4.35 M3 milestone Jan 18, 2025

stephan-herrmann modified the milestones: 4.35 M3, MilestoneNxt Feb 13, 2025

Merge branch 'eclipse-jdt:master' into gh2620-2

6627f62

angelickite mentioned this pull request Oct 4, 2025

Faulty/Undesired CodeCompletion behaviour #2620

Open

angelickite added 2 commits October 4, 2025 16:45

rollback L-Paren checks, add argument persistence

2a43061

the L-Paren checks were redundant as `CompletionOnMessageSendName` already guarantees the cursor to be in a "good position".

add test to observe argument preservation, adjust existing tests

1cfe27b

Conversation

angelickite commented Nov 26, 2024

What it does

How to test

Author checklist

Uh oh!

jukzi Nov 26, 2024

Choose a reason for hiding this comment

Uh oh!

jukzi Nov 26, 2024

Choose a reason for hiding this comment

Uh oh!

jukzi Nov 26, 2024

Choose a reason for hiding this comment

Uh oh!

jukzi Nov 26, 2024

Choose a reason for hiding this comment

Uh oh!

jukzi Nov 26, 2024

Choose a reason for hiding this comment

Uh oh!

jukzi Nov 26, 2024

Choose a reason for hiding this comment

Uh oh!

stephan-herrmann Jan 18, 2025

Choose a reason for hiding this comment

Uh oh!

stephan-herrmann commented Jan 18, 2025

Uh oh!

angelickite commented Jan 18, 2025

Uh oh!

stephan-herrmann commented Jan 18, 2025

Uh oh!

angelickite commented Jan 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

stephan-herrmann commented Aug 9, 2025

Uh oh!

angelickite commented Oct 4, 2025

Uh oh!

angelickite commented Dec 22, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

angelickite commented Jan 19, 2025 •

edited

Loading