`f` breaks when user define multi stroke keymap start with `f`.

[t9md]

Continuation of #254
In my current understanding, I can't fix by vmp side, need to improve Atom's keymap system.

This is not only f, theoretically all command which read user input via mini editor affects.

Problem

When user define f j keymap for some command,

'atom-text-editor.vim-mode-plus.normal-mode':
 'f j': 'dev:hello'

Default f(find) command also break. So when I type fa to find a char, it fail, throw error.

Why?

Atom keymap enter pending state when multiple keybinding matches.
When keymap choice was settled, atom replay keystroke.
When atom replaying keystroke it use original event.target.
So for command like f, it change focsed element to read user input from mini-editor, it fail to eat replayed keystroke(Atom don't send keyevent to this newly focused element).

How to fix

Should create issue to atom-keymap.
I'll send PR If I can(need to learn how to test custom atom-keymap in Atom).

What I want is

I think it's also difficult to let atom-keymap check target's focused element change in earch dispatch of keyBoardEvent dispatch.

So as compromise, I want atom-keymap provide API I can write this way.

atom.keymap.updateTarget(newFocusedElement) if atom.keymap.isReplaying()

By manually let atom.keymap know the change of dom focus, replayed keystroke correctly go into new focused element.

[t9md]

atom/atom-keymap#132 was merged after half year later!
This code is available in Atom-beta, after this become stable, I can close this issue. and revert mark operator code which was changed to work around this issue(since I wanted to user m as prefix key.

[t9md]

Unfortunately once merged above PR was reverted because of atom-keymap design.
The reason is understandable, but this mean we cannot fix, no-control against "custom keymaps sometimes work, sometimes breaks feature" situation.

This was the issue when vim-mode-plus used mini-editor as hidden input form.
But now vim-mode-plus uses no mini-editor, it now read user-input via keymap(char-by-char mapping), so fortunately no longer affected this atom-keymap's bug(or limitation).

So no longer problem in vim-mode-plus.
But when I revert to hidden input-form to old mini-editor approach, this issue will re-appear.

The pros and cons are

• mini-editor

  • good: simple implementation
  • bad: user's custom keymap easily broke feature
  • bad: was slow because of vmp is slower than original vim-mode

• current approach(read input via keymap by temporarily change scope when input started)

  • good: faster than mini-editor approach
  • good: no issue with user's custom keymap.
  • bad: hacky implementation, no multi-byte support, swapping scope only for different keymap table.