CompletionItem of completions response always have start = 0 and text prefix inclusion is mixed

I noticed recently that in nvim-dap, if you complete com. and select an entry you get com.com... inserted, so today I took a closer look and noticed that the responses from java-debug are somewhat odd - and I think incorrect.

With a client that specified columnsStartAt1 = true, and a completions payload like:

{
    frameId = <frameId>,
    text = "List.",
    column = 6
}

The responses include:

  }, {
    label = "of(E e1, E e2, E e3, E e4) : List<E>",
    number = 0,
    sortText = "999999179",
    start = 0,
    text = "of()",
    type = "function"
  }, {

The specification says:

/**

Start position (within the text attribute of the completions request)

where the completion text is added. The position is measured in UTF-16 code

units and the client capability columnsStartAt1 determines whether it is

0- or 1-based. If the start position is omitted the text is added at the

location specified by the column attribute of the completions request.
*/
start?: number;

The expected result for the user is to have List.of() if the completion candidate is selected. Now, start=0 is already odd given the columnsStartAt1, so a possible interpretation in the client is that it's absent, and that the client should just append .of()

This is kinda what I did in nvim-dap so far, and it works for the List.of case, and also for variables, but with a payload like:

{
  column = 5,
  frameId = <frameId>,
  text = "com."
}

I get responses like:

  }, {
    label = "com.sun.tools.example",
    number = 0,
    sortText = "999999183",
    start = 0,
    text = "com.sun.tools.example",
    type = "module"
  }, {

Opposed to the List. result, here text includes the prefix com. and it's again start=0. This led to com.com.sun.tools.example

I suspect vscode does some kind of prefix matching on the client side again, so this isn't noticable there?
As far as I can tell, based on the specification the current behavior is wrong.

I used JDK 21 in my tests - in case it matters.
I can also provide some sample project if needed - but I tried to use examples that should behave similar with only the JDK as dependency

Handle replaceStart/replaceEnd in completion proposal

java-debug/com.microsoft.java.debug.core/src/main/java/com/microsoft/java/debug/core/protocol/Types.java

Lines 348 to 358 in 736dcac

    
               public static class CompletionItem { 
        
                   public String label; 
        
                   public String text; 
        
                   public String type; 
        
                   /** 
        
                    * A string that should be used when comparing this item with other items. 
        
                    */ 
        
                   public String sortText; 
        
                   public int start; 
        
                   public int number;

start = 0 should be a bug. We don't assign a value to start attribute of CompletionItem intentionally, and it's the Java compiler that gives it a default value 0 during json serialization. Our purpose is to always insert, I think we should remove start and number fields from our protocol data structure.

Mathias Fußenegger (@mfussenegger)

Hi Mathias Fußenegger (@mfussenegger), I'm an AI Support assistant here to help with your issue. While the team reviews your request, I wanted to provide some possible tips and documentation that might help you in the meantime.

– According to the DAP spec, you can avoid these prefix-duplication issues by using a TextEdit rather than raw text+start:
• Fill in textEdit.range to cover exactly the existing prefix (e.g. from the dot back to after the identifier) and set textEdit.newText to the remainder of the completion.
• See https://microsoft.github.io/debug-adapter-protocol/specification#Types_TextEdit

– If you prefer start+text, compute start as the prefix length in UTF-16 code units (respecting columnsStartAt1). For example, for “com.” (prefixLen = 4), send start: 4, text: "sun.tools.example". Omitting start also defaults to inserting at the request’s column.

Other references with low confidence:

Use textEdit instead of insertText to avoid ambiguous (eclipse-jdt.ls#2679)

• Discusses switching from insertText+additionalTextEdits to a single textEdit to avoid overlapping prefixes.
• URL: eclipse-jdtls/eclipse.jdt.ls#2679 (comment)

The team will respond to your issue shortly. I hope these suggestions are helpful in the meantime. If this comment helped you, please give it a 👍. If the suggestion was not helpful or incorrect, please give it a 👎. Your feedback helps us improve!

Navigation Menu

Repository navigation

CompletionItem of completions response always have `start = 0` and text prefix inclusion is mixed #524

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	public static class CompletionItem {
	public String label;
	public String text;
	public String type;
	/**
	* A string that should be used when comparing this item with other items.
	*/
	public String sortText;

	public int start;
	public int number;

CompletionItem of completions response always have start = 0 and text prefix inclusion is mixed #524

Description

Activity

testforstephen commented on Mar 21, 2024

github-actions commented on Nov 14, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

CompletionItem of completions response always have `start = 0` and text prefix inclusion is mixed #524