Backwards keyboard selection resets to forward

[danthe1st]

When opening an XML file with the Generic Code Editor and selecting content with the keyboard starting from the end of the selection and walking back doesn't keep "selecting back" but switches to the end of the selection.

To illustrate this, take this video:

out.mp4

To record this, I opened an XML file, held Ctrl+Shift and pressed the Up arrow key followed by the Left arrow key a few times.

I would expect the selection to work as shown in the following video:

expected.mp4

This can be reproduced using the latest Eclipse version (with WildWebDeveloper) or by building and running it as an "Eclipse Application" with the org.eclipse.wildwebdeveloper.xml plug-in.

The issue only happens when the selection spans over multiple lines XML tags.

I am using Ubuntu 25.04.

[danthe1st]

The issue seems to be "caused" by these two lines in lsp4e and linked editing.
With "caused", I mean that commenting out these lines fixes the issue.

A part of the problem seems to be that https://github.com/eclipse-lemminx/lemminx/blob/ab8aa3fa110db899b74eef41c7bd375b60137314/org.eclipse.lemminx/src/main/java/org/eclipse/lemminx/services/XMLLinkedEditing.java#L59 finds linked editing ranges when making a selection that goes over multiple XML tags. If ranges is set to be empty, the issue doesn't appear.

[danthe1st]

So essentially, the following is happening:

• The user makes a selection that exceeds the span of one tag
• As the cursor is now somewhere else, linked editing (e.g. the outline) should update
• This updates the selection which is then set back but changing the selection also updates the cursor position to the end of the selection.

One fix would be to avoid updating linked editors when the selection changes but only update it when the cursor is changing without the number of selected characters.

[laeubi]

@danthe1st I also noticed that backward selection is simply a mess, it feels very laggy (if it works at all) compared to "forward" selection.

[mickaelistria]

The issue is more on client (LSP4E) side than on language server one. Basically, the LS is not aware of a "selection", it only asks for an offset. So in the case demonstrated in the video, LSP4E should do nothing (yet not bug would occur).
There are at least 2 possible ways, both viable yet more or less powerful, to decide whether to "do nothing" or "apply linked edit":

• LSP4E could just fully skip querying the LS when selection length > 0; refining condition on https://github.com/eclipse-lsp4e/lsp4e/blob/4a429af29a1c52098bb18fa1563afd2765740a83/org.eclipse.lsp4e/src/org/eclipse/lsp4e/operations/linkedediting/LSPLinkedEditingReconcilingStrategy.java#L162
• LSP4E could still query the linkedEdit ranges from the LS, but only apply them if the current selection is entirely contained in one of the ranges

[laeubi]

By the way I just wanted to notice that the same happens when selection with the mouse.

[danthe1st]

When it happened with the mouse, I thought it was my mouse acting weird 😂

[laeubi]

When it happened with the mouse, I thought it was my mouse acting weird 😂

I also assumed this first, but after a while now I only see this behavior in the Generic Editor especially when XML content is there, but not in others. And as it looks like your keyboard example and I only later realized that you are specifically refer to the keyboard its quite likely the same effect.