Scala 3 handles this case correctly. I spent some time looking at the Scala 3 version of this code and realized from there that all of this reverse engineering of where the identifier starts is unnecessary - I think we can just use refTree.span.point

Scala 3 code - almost all of which is actually about cases Scala 2 doesn't worry about. The case for RefTree is what is relevant here.

Thanks!

It doesn't seem to work in the REPL, so there's something else in the way there. It's fine with me if you want to leave that aside.

But I wonder if returning Foo Bar for completing `Foo ` works as expected, i.e., if the backticks stay in place and we get `Foo Bar`. Is that the positionDelta in CompletionResult? Can we check that in the test?

Did you check if completing `Foo without a closing backtick is possible? Completing Option[Str for example also works.

It would also be nice if X.Foo completes to X.`Foo Bar`.

It doesn't seem to work in the REPL, so there's something else in the way there. It's fine with me if you want to leave that aside.
...
It would also be nice if X.Foo completes to X.Foo Bar.

I think those might be due to pre-existing gaps. I'll double check though. Especially the first point surprises me a bit. I'd expect that if you have the closing backtick, the completion should work...

But I wonder if returning Foo Bar for completing Foo works as expected, i.e., if the backticks stay in place and we get Foo Bar. Is that the positionDelta in CompletionResult? Can we check that in the test?

I think so, but I'll check. I've been using this while exploring scalameta/metals-feature-requests#418 (see the screenshots there - the behavior at least through metals keeps the backticks in place).

Did you check if completing `Foo without a closing backtick is possible? Completing Option[Str for example also works.

That won't work yet - we'd need to back port this logic. This matters less for Metals since we can instead configure editors to auto-close backticks (plus that's more robust if you are in the middle of a line - the rest of your line doesn't get parsed into the backticked ident)

Alright, I did a loop here and I don't think there's anything further I want to investigate for now. LMK if that's OK.

I unsuccessfully took a stab at getting the REPL to support correctly adding backticks (scala/bug#6919) just in case I could use that to determine definitively the "right" positionDelta value - this is my first time using jline and the logic around the words is tricky (I got to the point that some things we're being backticked correctly, but other things would crash).

I've since made the LSP half of this change for Scala 3.6 (scala/scala3#22555). My plan is to get this PR merged and then merge scalameta/metals#7204 to get roughly the same behavior in 2.13.x.

@lrytz When do you expect Scala 2.13.17 to be released? Looking at the last several releases in the 2.13.x, it seems like they are roughly every 4-6 month, so that would but 2.13.17 around June, right?

@harpocrates in short, we don't know for sure yet (see https://contributors.scala-lang.org/t/scala-2-13-17-release-planning/6994) but yes, 4–6 months is a good guess. we don't currently have a reason to do it faster

It is possible to work around it in Metals by switching to a method, that will match on the changed cases and use completionsAt otherwise.