Thanks for the quick response!
@5e-Cleric Think along the lines of a multi-pane editor that displays files side-by-side. eg in VS Code, you can hit Ctrl+\ and the current tab splits in half and you get 2 editor instances on screen at once.
There are actually two flavors of this problem:
- The editor instances share document state, as in VS Code’s split command. The editors are both views in to the same file, so you can scroll them independently, but any changes you make in one editor are immediately visible in the other.
- The editor instances are completely independent with their own document state; they just happen to be displayed next to each other on screen. (You can do this in VS Code as well by dragging a tab to the side of the window, giving you a split pane view with different files.)
For the former, I know there’s a demo that shows you how to achieve split panes in CM.
My particular use case is actually closer to the latter — my UI can have multiple panes but the editors’ document states are independent. However, the functionality I want to achieve is slightly different from either case, where only one editor can have input focus at a time, and any changes appearing in both panes is simply a side effect of shared document state.
Basically, I plan on my app UI allowing the user to select additional editor(s) to receive secondary “focus” (probably by Ctrl-clicking the secondary editor at the location the user wants to place the secondary cursor). I know this isn’t real focus, so I’ll use CSS to fake it to look like focus. Then the user can start typing and the effects of each keypress are applied to all selected editors. (Except Esc, which returns focus to only the primary editor.)
So spiritually similar to how multiple cursors within an editor work, just across separate editors that have independent documents.
@marijn I suppose I could listen to the change transactions coming out of the primary (actually-focused) editor by overriding dispatch (as in the split pane example), but I’ll have to somehow transform the from/to positions to adjust for arbitrarily-placed cursors. I imagine things will get tricky if the user activates multiple selections within an editor, especially given that the documents aren’t necessarily related.
Or would it make more sense to just use the DOM to dispatchEvent(…) with a synthetic KeybaordEvent to forward keypresses into the secondary editor, and let it process input normally? Of course, then clipboard handling gets tricky, as does inserting accepted autocompletions…
Or are you thinking I’d need to do some combination of those approaches?