Implement operator-pending mode

[atom]

Implement operator-pending mode

[graywh]

Sounds like Atom needs an operator-pending mode.

[bashcoder]

Yes, that might allow for other vim compatibility fixes such as daw, caw and the like.

[bashcoder]

Another example is ctX, where "X" is the variable character marking the end of the change zone.

[keyneston]

In addition there is the tX and fX along with all of its variations: dtX, yfX, etc.

[stuartmemo]

I'm happy to close this if someone wants to create a new ticket with a better description that incorporates all these things?

[mcolyer]

👍 to the operator pending mode, also feel free to edit the issue description/title. Usually I shy away from editing issue descriptions and titles but I think it's fine in a case like this.

[jroes]

There is some semblance of operator pending going on with the @complete instance variable in operators.coffee, but I think an operator pending mode might make it more explicit and potentially simplify some code. These are the only operators vim officially considers operators - c, d, y, ~, g~, gu, gU, !, =, gq, g?, >, <, zf, g@ I think operators.coffee has a few outliers that we might be able to move to commands.coffee.

If we ever want to implement those multi-character operators, I think we need to start doing timeout stuff. It would actually be awesome if we had direct support for this in atom. For example, I've always bound jk to Esc, and binding j k in my local keymap causes issues in vim-mode :(.

[stuartmemo]

Have updated title to "Implement operator-pending mode".

[mcolyer]

@jroes 👍 on a more correct operator pending mode and making things generally more correct.

As for the timeout stuff that's honestly what stopped the progress on these more complex commands. Atom's keybinding infrastructure was never really intended to have multiple separate key presses (ie keypresses are considered independently, not within a state machine). I think we can get it there but it just hasn't been a priority.

[jroes]

I'm off to a slow start guys, this is a little challenging (but fun!) :)

So far what I've done:

• I created a TextObject subclass of Motion for storing all of our new text objects, and an InnerWord subclass of TextObject that selects the current word under the cursor like vim's iw
• I implemented an operator-pending mode that looks pretty much exactly like the other modes.
• I copied a bunch of keymaps into the operator-pending mode map. This felt like a lot of duplication, maybe there is a better way to handle this.
• I spent some time trying to see if I needed to make any changes to the meaty part of how the operator stack works. After a lot of toying around, I think I found that we are probably going to need this stack, but the name was confusing me a bit. I renamed several spots from operator to operation to better communicate that this is a stack of operations that are being performed, these operations may be operators, motions, text objects, or something else. The way I'm thinking of opStack is as an internal representation of something like "d2w". I documented this for future code spelunkers. I hope this is in line with the overall project vision.
• I was able to bind i w on its own in visual-mode with no special help there since i isn't already bound. However, I noticed that in vim you can type iw a bunch of times in visual mode and it'll work like w after the first time. I was going to leave that as a future exercise outside of whatever pull request I make for operator-mode

So I think this is a small toe-dip in the waters. From here we should be able to implement aw and several other things simply because the mode has its own context for key bindings and won't interfere with the other bindings. I still think we are going to hit problems where we'll need timeouts though. Hopefully that gets into Atom sooner or later.

Here's a compare for my current branch: jroes/vim-mode@atom:master...jroes:operator-pending
@mcolyer, everyone - what do you think, does this line up with your thinking? At this point all tests pass, so I could make a PR to stop this from turning into a really really big PR, and then we can all make some successive PRs for various text objects and things that should happen in operator-pending mode.

[jroes]

Oh, forgot to mention -- I'm actually not putting us into operator-pending mode for every valid operator yet. I thought it would be better to do that one at a time as we need it. Doing it all at once brings with it a ton of test failures that will take some time to dig through.

[ElDeveloper]

Just adding a note about vip see #111.

[jroes]

ping -- anyone have a chance to offer some feedback on my comments above?

[bhuga]

@jroes, can you make a pull request out of your branch? That will make it a little easier to talk about.

[jroes]

Will do @bhuga. It has drifted a bit. I've rebased, but there are some test failures now that I'll have to look through and address.

[bhuga]

Added in #152