Closed RandomDummy closed 1 week ago
This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!
This feature request has not yet received the 20 community upvotes it takes to make to our backlog. 10 days to go. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!
:slightly_frowning_face: In the last 60 days, this feature request has received less than 20 community upvotes and we closed it. Still a big Thank You to you for taking the time to create this issue! To learn more about how we handle feature requests, please see our documentation.
Happy Coding!
Context
When moving vertically, cursors keeps track of their initial column. For instance in the following setup:
A cursor starting on
s
moving down twice The expected behavior is toi
, thenc
. Without this "column memory", it would end up at the positionw
.Feature request
The goal of this feature request is to reuse this "column memory" in the context of a mouse click. For instance with the following setup:
With a mouse click on
X
, the cursor would visibly be set ons
. Moving down currently lead toc
, the request is to go tof
instead.This makes keyboard adjustment after missing selecting long lines shorter.
Improving the usability of selection tools with low accuracy/precision (e.g. eye tracking).
Internally, the "column memory" works through the property
leftoverVisibleColumns
. The formula seems to beinitialColumn = cursor.column + cursor.leftoverVisibleColumns
?A distinction is made between 2 kind of cursor's position: "model" (actual text position) and "visual" (within the editor (seems to account for line wrapping, and injected text)).
From my limited testing, setting the visual position's
leftoverVisibleColumns
tomouseColumn - visualColumn
is sufficient to handle the behavior.Edge case: click under the textarea
There is an edge case when clicking under the last line:
The cursor gets move to the end of the text and
mouseColumn - visualColumn
ends up negative. Negative values seems to snap the cursor back a few characters on the next vertical motion.(input: click on 'X', then move up once):
(
X
: position of the click,s
: visual position of the cursor,f
: cursor after moving up with negativeleftoverVisibleColumns
,c
: current behavior)It's a strange behavior but somehow not too far from the keyboard's:
Starting at
s
:s
,1
,2
,s
s
,1
,2
,2
,e
Not sure if bug or feature, and even less if expending it to the mouse would make sens.
As for drilling the relevant values down to where there would need to be used, the relevant part of the stack trace seems to be:
The 1) is the last function having access to the mouseColumn, the 4) is the function setting the
leftoverVisibleColumns
to an hardcoded 0.Also, ViewController has access to a IComputedEditorOption making it the ideal place for a feature switch.
If mouseColumn was to be drilled through the above call stack, there are 2 points that seems delicate to me:
adding mouseColumn to
ViewController#moveTo
This is a public function of an exported class (could be used by 3rd party). I see 2 way the drilling could go:
cursorColumn: number? = null
Adding the parameter to the existing function would allow 3rd party's code with access to a ViewController to set arbitrary cursor offset.
adding a property to
MoveCommandOptions
to carry column infoThe commands using
MoveCommandOptions
(or derivated) are:_moveTo
,_moveToSelect
,createCursor
,_lastCursorMoveToSelect
_wordSelect
,_wordSelectDrag
,lastCursorWordSelect
_lineSelect
,_lineSelectDrag
,lastCursorLineSelect
,lastCursorLineSelectDrag
If the change was extended to commands other than
_moveTo
, it would probably be_moveToSelect
,createCursor
,_lastCursorMoveToSelect
.So, to recap the main points left to address:
leftoverVisibleColumns
? clamp to a positive/zero value ?)