You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Highlights and inlay hints randomly get offset #272
I don't know if this is a bug with the extension, Zed or JDTLS, but it has been happening for months so I figured I might as well report it and hopefully one of you guys here can find where the actual issue is.
Like the issue title says, there is a disconnect between the positions where highlights and inlay hints should be in the code and where Zed displays them.
Here is a screenshot of the parameter name inlay hints to show what I mean:
And what it should look like:
And here for highlights (I have the cursor inside lastName here):
I haven't figured out what it is that triggers this; it just happens every now and then when I edit the code in a file. It also does not happen across the entire file; it starts at some point and then gradually gets worse the further down the file I go from there. If I make any change to the file and save it, the LSP will refresh the information and everything ends up in the right spot again (i.e. the offset issue disappears).
This is quite annoying, although not vital since it disappears after doing an edit and saving.
Interesting, I haven't had this kind of issue myself. This is just a hunch, but it might have something to do with /r/n line breaks getting replaced with /n in some places and not others (or counted as 1 char some places and 2 chars in others), and thus leading to discrepancies in offsets.
Do you by chance have a formatter that will auto-replace /r/n with /n or vice versa on save?
I have also been thinking it might be related to Windows line breaks, but I'm not sure exactly how.
I use the default formatter from JDTLS ("Java" : { "formatter" : "language_server" } in Zed settings, with no additional configuration).
I have "format on save" turned off in Zed, but "remove trailing whitespace on save" and "ensure final newline on save" are both turned on. "Line ending" is set to "detect".
I have found a way to consistently reproduce the offseting:
Open a java source file that contains several unambiguous imports (i.e. imported classes with unique names).
Delete a bunch of the imports and save the file.
Use the editor: organize imports Zed action or the All all missing imports code action from JDTLS to automatically re-add the imports you removed.
Save the file.
Voilà! The highlights should be bugged.
I used the above to get a file into a bugged state and then I made a hexdump of the file. Then I "fixed" the file by adding a space in the middle of a word, saving, removing the space, saving. Comparing the hexdump of the file before and after shows no difference at all. So the bug is not caused by e.g. mixed line endings in the saved state of the file; it seems to be something that's completely in-memory.
Before the summer I installed Zed inside WSL instead of using the Windows version on my work laptop and I haven't had the issues since. I still have Zed in Windows on my home PC so I can test there when the patch has been released (and I am back home; travelling at the moment).
Activity
playdohface commentedon Jun 16, 2026
Interesting, I haven't had this kind of issue myself. This is just a hunch, but it might have something to do with
/r/nline breaks getting replaced with/nin some places and not others (or counted as 1 char some places and 2 chars in others), and thus leading to discrepancies in offsets.Do you by chance have a formatter that will auto-replace
/r/nwith/nor vice versa on save?Komposten commentedon Jul 1, 2026
I have also been thinking it might be related to Windows line breaks, but I'm not sure exactly how.
I use the default formatter from JDTLS (
"Java" : { "formatter" : "language_server" }in Zed settings, with no additional configuration).I have "format on save" turned off in Zed, but "remove trailing whitespace on save" and "ensure final newline on save" are both turned on. "Line ending" is set to "detect".
Komposten commentedon Jul 3, 2026
I have found a way to consistently reproduce the offseting:
editor: organize importsZed action or theAll all missing importscode action from JDTLS to automatically re-add the imports you removed.I used the above to get a file into a bugged state and then I made a hexdump of the file. Then I "fixed" the file by adding a space in the middle of a word, saving, removing the space, saving. Comparing the hexdump of the file before and after shows no difference at all. So the bug is not caused by e.g. mixed line endings in the saved state of the file; it seems to be something that's completely in-memory.
playdohface commentedon Jul 28, 2026
fwiw I tried to reproduce and for me all looks correct.
It reminds me of this one: zed-industries/zed#60031 maybe they are related?
tartarughina commentedon Sep 24, 2026
zed-industries/zed@532532b this might fix the issue here reported
Komposten commentedon Sep 27, 2026
Before the summer I installed Zed inside WSL instead of using the Windows version on my work laptop and I haven't had the issues since. I still have Zed in Windows on my home PC so I can test there when the patch has been released (and I am back home; travelling at the moment).