microsoft / microsoft/java-debug

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

Open
#524 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

ai-triaged bug
Dominant language
Java
Stars
409
Forks
204
Avg merge
1d 13h
Merged PRs (30d)
4

Description

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

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing the Java debug server's DAP completions handling for the completions request and CompletionItem response, using the JDK 21 examples in the report. Reproduce the List. and com. cases with a client such as nvim-dap, then verify that start and text follow the DAP specification and selecting each candidate inserts the expected completion without duplicating its prefix.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
devtools
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.