WrappedLine information in API

[xconverge]

I am trying to determine wrappedLine information about what position.column is the start of the line and what position.column is the end of the line so that I can move relative to wrapped lines.

I tried this:

await vscode.commands.executeCommand("cursorMove", {
	to: "wrappedLineStart"
});

const startCol = vscode.window.activeTextEditor.selection.active.character;

await vscode.commands.executeCommand("cursorMove", {
	to: "wrappedLineEnd"
});

const endCol = vscode.window.activeTextEditor.selection.active.character;

But I really don't have the ability to move the cursor around so much just to find this information.

This is needed in the VSCodeVim extension. There are quite a few motions that are relative to wrapped lines. Currently we rely on the cursorMove command which has a method to deal with wrapped lines, however if we want to do something else like a diagonal move, up a line and over etc, it is not possible.

[alexdima]

We have no plans to expose wrapping information to the extension host. In fact, only the core of the editor knows about wrapping (the rationale is that it is quite difficult to work with two coordinate systems and it is something only a small number of actions/scenarios would ever care about). There is also the case of folding, etc, which makes things additionally complex.

I suggest we come up with a prioritized list of motions you're missing, and we can continue to handle them via cursorMove, with new arguments so you can continue to delegate in these cases to us.

[xconverge]

Hmm ok, unfortunately this is very vim type behavior and I have no idea how I can achieve it without this information.

Many users configure their movement keys to move by wrapped line(where we now have to delegate) instead of normal.

As you move down, we keep track of what is called the desired column. This means if you want to go from

Here|
To
Here

Where | is the cursor, you just go down twice and the column is attempted to be maintained.

Here
To
Here|

If we delegate and user cursorMove you can see how it would only send down moves

Here
To
He|re

Without knowing what column I actually want to get to because we delegated, this is impossible.

[xconverge]

Adding a desired column type argument to the API call seems silly, and oddly specific

[alexdima]

Funny you mention that, the core cursor has the same concept and AFAIK the cursorMove maintains that information. e.g.

use the following in keybindings.json

{
        "key": "ctrl+up",
        "command": "cursorMove",
        "args": {
            "to": "up",
            "by": "line"
        },
        "when": "editorTextFocus"
    }

press ctrl+up and observe that it respects this concept of desired column.

[xconverge]

Whoa, thanks @alexandrudima

I think I can work with that, sorry I didn't realize it was retaining that! It is just a bit complicated to be managing it on both sides, but I can ignore updating it as long as we are delegating to vscode.

[xconverge]

is it possible that your keybinding does something different than:

    await vscode.commands.executeCommand("cursorMove", {
      to: "up",
      by: "wrappedLine"
    });

I can't seem to get this call to do the same thing...

[xconverge]

@alexandrudima not sure if you saw my last comment but the keybinding works, but the same call through the API does not :/

[alexdima]

@xconverge That "hidden" state is reset if textEditor.selection(s) is written to.

The following extension works fine for me:

var vscode = require('vscode');

function activate(context) {

    var disposable = vscode.commands.registerCommand('extension.sayHello', function () {
        vscode.commands.executeCommand('cursorMove', {
            to: "up",
            by: "wrappedLine"
        });
    });
    context.subscriptions.push(disposable);
}
exports.activate = activate;

The cursor moves up by one view line and maintains the hidden state when I trigger the command from the F1 list repeatedly.

[rebornix]

Our gj, gk in Vim is using cursorMove, Code will take care of this command and make sure it gets correct position. After that we receive a selection change event and handleSelectionChange in Vim extension kicks in. And then we update our internal selection. From what I can tell, everything goes reasonably.

[xconverge]

This is where it gets a little confusing without the API from the ticket here though...
In vim, you cant move the cursor past the last character. If I use cursor up to a line with 1 character, it will be in the wrong position. I need to go up but also potentially adjust the position...and maintain the hidden state...I just really don't think it's possible right now

I can make some gifs if that helps.

I think that this ticket needs to at least be open until I see a way out... @rebornix remap j to gj and k to gk and try to use the extension for a day. This is a somewhat common setting for people to use so that you are never messing around with wrapped lines and the interaction is seamless.

[xconverge]

@rebornix @alexandrudima I still would like wrapped line info, I cannot get it to work right in any cases and having more info from the API would solve it... If it is really not going to happen, maybe @rebornix can take a stab at some of these issues and come up with a better way of handling the interaction from both sides related to this

[Chillee]

@alexandrudima You said this:

Funny you mention that, the core cursor has the same concept and AFAIK the cursorMove maintains that information. e.g.

We would love to leverage this in built functionality for moving around, and I hacked up an implementation that works mostly well, except for one issue.

In vim, you can't place the cursor on the very last position of the line. So when you move up a line from, say

foo
foob|a|r

you end up with

fo|o|
foobar

However, if we just try and leverage Vscode's APIs, we end up here

foo| |
foobar

Normally, this isn't an issue as we just shift the cursor one left if it's at the end of the line. However, as you said,

That "hidden" state is reset if textEditor.selection(s) is written to.

and shifting the cursor left necessarily necessitates writing to textEditor.selection. As such, we need another solution to do this robustly.

[alexdima]

@Chillee One idea would be for us to change our behaviour based on the cursor style, i.e. if it is a block or a line. But I'm not sure that would cover all cases.

Regarding the API, there is some discussion going on in #22276

[Chillee]

@alexandrudima Yeah I saw that. I really appreciate the in depth post on the difficulties of the API. From the perspective of the API user, it's often easy to forget all of the design choices/decisions that go into the API design, to minimize technical debt, to align with the current infrastructure, etc.

As for the proposed solution, I'm not sure about that. If people are using block cursor while not in vim mode, that would prevent them from inserting onto the end of the line. Perhaps a flag is possible? This might be too much of a niche case to add a flag though...