Fail to emulate user's input when focused element changed in middle of replaying keystroke.

[t9md]

This is feature enhancement request to solve following problem, limitation.

Problem scenario

Following keymap is not actual scenario I'm facing. But for clarity.

When I have following keymap, keystroke cmd-t a don't put a character to fuzzy-finder's mini-editor.
Without this keymap(default), cmd-t a keystroke put a char to fuzz-finder's mini-editor.
I want put a on mini-editor even if I set following keymap.

'atom-workspace:not([mini])':
  'cmd-t': 'fuzzy-finder:toggle-file-finder' # default for mac 
  'cmd-t t': 'tree-view:toggle'

Reason

When atom-keymap replaying keystroke, it replaying against original event.target, not aware of focused element change.

Proposal to fix

idea-1

Change this line.

From

target = event.target

To

target = if replay then document.activeElement else event.target

idea-2

Provides public API to manually inform focus change to atom.keymap.

# change focus to read input from user
miniEditorElement.focus()
if atom.keymap.isReplaying()
  # explicitly inform focus change to replayed keystroke goes this element.
  atom.keymap.updateTarget(newFocusedElement)

Background

I'm developing vim-mode-plus(this issue is also affect official vim-mode).

t9md/atom-vim-mode-plus#260
t9md/atom-vim-mode-plus#254

For example, vim-mode has m command to mark current cursor position.
m take single a to z char from user via mini-editor.
So user can save cursor position to a mark by ma, to b mark by mb.
Since I don't need such big number of mark, I want to map mm to different command.
But after I set "m m": "different-command" keymap, original m breaks.

E.g. The keystroke md to save position to d mark will throw error(in vim-mode, vim-mode-plus case).

Why? replayed d is handled by oringal event.target(=editorElement) and d matches vim-mode-plus:delete command.
But this is unexpected scenario where another operation command is pushed to vim-mode-plus's operationStack while previous command m(mark) command have not yet finished(in this timing vim-mode is just waiting mark char through mini-editor).

[t9md]

@nathansobo Should this issue keep opened since the PR was reverted?

[nathansobo]

@t9md I'm bordering on just saying "won't fix" for this because keystroke sequences are tied to selectors that are intended to match against individual elements. Can you articulate the exact problem you're trying to solve?

[t9md]

I put on Background section above, but will try to explain again.

• I'm developing vim-mode-plus.
• vim-mode-plus have several command which takes input from user via mini editor.
• These commands are m(Mark), f(Find), F(Find Backward), "(Set register) etc..
• Take m as an example

1. In normal-mode, m a, create a mark at cursor position. m b create b mark, it's bookmark like feature. To read mark character(a, b etc) vim-mode-plus use mini-editor input(but intentionally hidden to user). So when user type m, activeElement will change to new mini-editor.
2. But I don't needs such big number of bookmark, so I map m m to different command in keymap.cson.
3. At this point, m become partial-match and when next character was typed, keystroke is replayed.
4. But because of replay statically happens against original target, m a, m b, m c no longer work. a, b, c keystroke never sent to mini-editor. It's sent to m invoking text-editor-element.
5. Just setting m m keymap broke all m command and many user can easily do like this. And what was worse is many user can not understand why it broken. And situation when "text-editor-element get another keystroke immediately after focus changed to mini-editor" is never happening situation unless replay is involved, so it makes investigation difficult.