Anybody paying attention to this project?

[abaljeu]

I'm interested in experimenting with keyboard interfaces, and I'm fond of oomotion's scope-selection scheme and also its take on source code structuring. Consequently, I'm working on a fork. Now, to know if there's value in bringing improvements to the main project, I'd like to hear from whoever cares.

[YuantianDing]

Honestly, now I realize that I made a lot of design errors in this keymap. Yet I am quite busy working on other things. I would be happy if you want to take over this repository or discuss some keymap designs.

[abaljeu]

I have busied myself with fixing bugs.

I am definitely thinking about better keymap designs.

I'm pondering a facility to shrink the selection on top or bottom in addition to current grow and shift. I have other thoughts, and I'm curious to hear yours.

[abaljeu]

You mentioned design errors in the keymap. I'm wondering what you had in mind, if it was just choices of keys, or how the binding works or more fundamental aspects of the motion system. I have a variety of musings, and I'm not committed to any of this:

I dislike ^ for char mode. Obiously c h a and r are used so there's no mnemonic letter available. Oh well.

j, k make perfect sense in char or word modes, but in line mode, left and up are the same thing. In tree mode, forward and upward aren't clearly different.

The multicursor shortcuts seem odd in most cases other than line mode. Actually, the way I most like to do multi is from Helix: Select a larger scope and then s[text]<enter> and then you have lots of things with a cursor.

Word has an extended version to pick up the characters in-between words. I think most modes would benefit from the same thing.

I am a huge fan of fold operations in text editors. Unfortunately, many of the scope movements don't respect folding. Sometimes you want to delve into a fold, and sometimes you don't, mostly depends on your movement choice. Char, word, line moves would ideally go over, Tree naturally would because it's a tree item that was folded.
Search could dig in except if I'm searching for foobaz it's annoying that the first place an f occurs causes unfold to happen. VSCode normal Ctrl-F avoids this by not being incremental. Not sure I have a recommendation.

I did have a notion that instead of selection modes instantly taking effect, they wait for a cursor movement operation. This is a radical change, but I might like it. So

    if (foobaz == 32345) then
        return false
   foobaz = qwerty * 2

Suppose I go to the if line, select it line mode, then press wl. return is added to the selection. ll false and foobaz (line 3) are added. x line mode, selection unchanged. l or k the line is fully selected.

Connected to this mode switch, I also was imagining a "bigger/smaller" pair of keys. Starting at char, bigger moves up to small word, then word, then big word, then (maybe) line, etc.

If you or other people are interested in developments like any of these, I would work together to discuss the behavioral design and implement coding of the extension. Otherwise, I will do my own thing.

[YuantianDing]

Thank you for your replies. Here are some of my thoughts:

I dislike ^ for char mode. Obiously c h a and r are used so there's no mnemonic letter available. Oh well.

I don't think char mode will be used very often. I normally go straight to the insert mode.

The multicursor shortcuts seem odd in most cases other than line mode. Actually, the way I most like to do multi is from Helix: Select a larger scope and then s[text] and then you have lots of things with a cursor.

My idea of multicursor is based on shift+n and shift+b keys. So for s[text]<enter>, what I will do is to first select the first text and then use shift+n and shift+b to select other ones. For me this is more intuitive and flexible than texting the [text] manually.

You also can jump over some occurrence of the same word by adding a number before it, e.g. 2 shift+n will jump over one word occurrence of the same word. This is particularly useful in this case in Rust:

fn func(index: str) {
    let index = index.parse::<usize>();

    .... (a lot of occurrence of index)
}

Starting with word mode on the first index in the let binding, the second index can be jumped over using 2 shift+n and then repeating shift+n you can select all index within this function. The first index can be easily selected using easy-motion, without typing the word index itself.

And shift+l, shift+r in tree-sitter mode is quite useful for selecting multiple adjacent tree nodes. Although tree-sitter mode itself is terribly designed for now.

I am a huge fan of fold operations in text editors. Unfortunately, many of the scope movements don't respect folding. Sometimes you want to delve into a fold, and sometimes you don't, mostly depends on your movement choice. Char, word, line moves would ideally go over, Tree naturally would because it's a tree item that was folded.
Search could dig in except if I'm searching for foobaz it's annoying that the first place an f occurs causes unfold to happen. VSCode normal Ctrl-F avoids this by not being incremental. Not sure I have a recommendation.

Folds are interesting. I have a similar problem with Symbol Masks which automatically show a word as a special character. It's the same here, sometimes you want to show the inside while sometimes you don't.

I did have a notion that instead of selection modes instantly taking effect, they wait for a cursor movement operation. This is a radical change, but I might like it. So

The selection modes for me isn't a big thing. But I can feel this can improve the experience.

Connected to this mode switch, I also was imagining a "bigger/smaller" pair of keys. Starting at char, bigger moves up to small word, then word, then big word, then (maybe) line, etc.

Yeah. The tree-sitter mode now is very weird for now. I realized this problem few weeks later after implemented this keymap. This way is more intuitive. The only problem is you may have different levels can not be said to be "bigger" or "smaller". Like parenthesis () may sometimes bigger than lines, and may sometimes smaller than lines. So multiple trees of levels are needed. For examples, we may have one tree for tree-sitter, one for parenthesis and brackets, and another one for word/line/paragraphs.

If you or other people are interested in developments like any of these, I would work together to discuss the behavioral design and implement coding of the extension. Otherwise, I will do my own thing.

I'm very interested to join and make it a bigger project. Here I list some other thoughts:

• Selecting is easy while modifying is hard. I failed to make y/p command in Oomotion work naturally. Maybe it's even wiser to remove those commands and leave the key to others. With line copying & moving like alt+shift+k and alt+k and naive ctrl+c, ctrl+v. I couldn't find a lot use cases for y/p. I thought mostly people use y/p in vim to move/copy lines.
• I missed some useful commands in vim, like D to delete to the end of line and % to jump to a matched bracket, and also, keys to change parenthesis into brackets.
• m key is not well implemented. Changing to camel case is not very convenient.
• This version works very bad with integers. It's a question how to select the next incremental integer and how to update/sort them in a systematic and extendable approach.

[abaljeu]

I have to learn how the tree mode works more, by delving into tree-sitter itself. I feel there’s room for doing like word mode, where there is “select statement” and “select statement plus preceding whitespace”, as two variants, for example.

I’m not clear why y/p aren’t useful here. (I’m novice-level with Vim, so there’s plenty of nuances I’m not even aware of.) Copy selection and paste copied text are fine. Or yes Ctrl+C Ctrl+V also do the job.

I’m on-board with % bracket match. I have no context where i’d want to swap often () to [].

I’m going to experiment today with my experimental fork, different ways of selecting things.

[YuantianDing]

There are a lot things to consider in the tree mode. Better to provide a lot of variants to pick and choose.

I mean most of time alt+shift+k and alt+k in Oomotion can do the copying/moving job of y/p. Like alt+shift+k is basically y y P. Maybe there are more complex use cases for y/p in vim, but for me alt+shift+k and alt+k is an easier alternative.

I'm sorry I shouldn't say switching () to [] is a common case. Actually I mean in JavaScript, sometimes you want to swap "" with ``. This is often useful when you want to add string interpolations into an existing string.

[abaljeu]

Ah for the quotes, i'd say f select ", and change each selected to ```.

as for y/p, going to into Select , selecting multiple lines, or selecting a portion of a line and pressing y is the distinctive use case.

About modes, there are two families:

• char/subword/word/line/continuous block of lines
• and tree-sitter all the way up and down a syntax tree of the file.

vim's D / delete to end of line.. i'm exploring ideas like vxnd i.e. Select Line Forward Delete. Which of course is way more than D but it also gives you options of going to the end of a code block, copying instead of deleting, adjusting the selection after moving forward before editing.

[abaljeu]

I think it would be useful to open a discussions section of this. It's not clear all my comments really belong as issues.

Anyway, I finally am getting around to trying to work with treesitter code. It's failing at getParser() await Parser.init();

I'm struggling to figure out what needs to be done at this point. Could be a version conflict betwen wasm files or, I don't know.

EDIT: false alarm: my nodejs was out of date on this machine.

[abaljeu]

vim's D / delete to end of line.. i'm exploring ideas like vxnd i.e. Select Line Forward Delete. Which of course is way more than D but it also gives you options of going to the end of a code block, copying instead of deleting, adjusting the selection after moving forward before editing.

Don't like this suggestion anymore. New thought: holding the shift temporarily elevates the syntax level for the next motion. (caveat: shift is currently used by the cursor dup, and don't want to lose access to that magic).

So in character mode, l goes right one char, and L goes right to the end of the word. h is left one char, H left to the start of the word. J, K are up or down select the word.
In word mode, L is right to end-of-line.
In tree-sitter, L is typically to the end of current block, depending the level of tree we're working in.

The upshot is if you are in extend-select mode working on words, Ld deletes to end of line.

My thinking is if you also have the key to toggle to front/back of a selection you get a very fast intuitive navigation.