For example, if I wanted to edit this issue with vim, I would use the shortcut I set up and I expect this text to be present in editor when it starts; however, it is not, the buffer is empty.
Not to be a complainer (I love the idea of this), I realize this will be difficult to make work for all input fields. Various system's accessibility apis expose this information, so maybe something could be done with that?
I do realize that a trivial workaround is to to select the entire text field, copy, activate vim anywhere, and paste, but this is many steps, and context–such as cursor position–is lost.
Be in app, see something that needs editting
ctrl+a
ctrl+c
ctrl+alt+v
p
find thing that needs editting again
place cursor
versus
Be in app, see something that needs editing
place cursor
ctrl+alt+v
Potentially, the same accessibility apis may allow the original text field to be populated simultaneously with the vim buffer (I recall a browser plugin+editor plugin that required this sort of information exchange to update css live as it was editted in vim or sublime).
For example, if I wanted to edit this issue with vim, I would use the shortcut I set up and I expect this text to be present in editor when it starts; however, it is not, the buffer is empty.
Not to be a complainer (I love the idea of this), I realize this will be difficult to make work for all input fields. Various system's accessibility apis expose this information, so maybe something could be done with that?
I do realize that a trivial workaround is to to select the entire text field, copy, activate vim anywhere, and paste, but this is many steps, and context–such as cursor position–is lost.
versus
Potentially, the same accessibility apis may allow the original text field to be populated simultaneously with the vim buffer (I recall a browser plugin+editor plugin that required this sort of information exchange to update css live as it was editted in vim or sublime).