Set both selection and caret in Generic Code Editor

[danthe1st]

I am in the situation where the selection is set programmatically using the following:

ISourceViewer sourceCiewer = ...;
sourceViewer.getSelectionProvider().setSelection(someSelextion);

(or similar, e.g. setSelectionRanges)

However, this positions the caret (cursor) at the end of the selection but I want to position it differently.

I tried to use sourceViewer.getTextWidget.setCaretOffset() and similar but either the caret is position correctly (with nothing being selected - if I set the caret last) or the selection overwrites the caret.

For context: The selection is modified and is restored to its previous state causing a bug in wildwebdeveloper/lsp4e I want to get fixed and contributing it is the best way to actually get it done.

Any other way of saving and restoring the selection including the caret would be a useful alternative as well.

[mickaelistria]

I don't think the getSelection() API allows to get information about nor control the caret position, which makes sense since the getSelection() is about model more than widget. The caret position has to be set on widget level, you may have to used sourceViewer.getTextWidget().setSelection() with start > end or setSelectionRanges with negative length to build such selections.

[laeubi]

I don't think the getSelection() API allows to get information about nor control the caret position, which makes sense since the getSelection() is about model more than widget.

Actually we have ITextSelection, IMultiTextSelection and IMarkSelection so if we want to have an extension that covers carret positions it sounds reasonable (e.g place before/after).

[mickaelistria]

I don't think it's a good idea. There is a general pattern that JFace is an MVC framework, and that the JFace element should not surface much widget, rendering or interface logic (as it's SWT role). Making the selection framework extensible to make pure UI info (caret position) leak into model is not likely to simplify or clarify any code, it is more likely to make things more complex to use and more confusing to navigate.

[laeubi]

There is a general pattern that JFace is an MVC framework

Even though this is claimed I never found that JFace supports anything that is like a "model" (like Swing does) anyways having a TextSelection semantically includes that I want to make sure the carret (what is only a logical position in text) is on the right position. Also TextCompletion works that way that you obviously need the carret.

So even though one not want to name it "carret" it is nothing really related to a widget, in a models point of view it is the current position in the text where the next insert operation would take place.

Of course everything can be done by query the widget or manipulate it but this is exactly against MVC pattern, I simply do not need to know or even use the text widget for that.

[danthe1st]

Thank you for the idea of having a negative range. I'll see whether that would work (and whether it's useful/better in my use-case).