Support multiple cursors properly

[mathrick]

There should be solid support for multi-cursor operation, both at the algorithm level and the UI level.

For the Emacs UI substrate, this includes at least the following:

• Multiple regions, including the semantics of what constitutes a "region", and whether they're mandatorily tied to a point (ie. cursor) at one end, and how popping and pushing marks works with >1 point active. multiple-cursors.el has likely solved at least some of these problems already.
• Per-point ("run for all") commands, which are applied to each point/region, in a way that isolates each application and makes it appear as if only one point exists, bringing the required awareness of multi-point capabilities to a minimum. For almost all commands, this amount should be 0.
• Global ("run once") commands, which either operate in a manner independent of any points (for example M-x Switch Buffer), or do something specifically aware of multiple points
• Specific commands to manipulate the multiple points and regions themselves.

Run for all and run once commands could presumably be handled largely transparently by having appropriate mix-ins in the class hierarchy.

[mathrick]

Multiple cursors introduce certain complications for efficient editing. Splay trees are a good self-adjusting data structure where the current locus naturally becomes fast, but it requires there to be a locus. Whereas with multiple cursors, there are many, and it's not unreasonable to want thousands of cursors at once (many log file-like editing tasks are trivially expressed in terms of UI-level editing operation, but very cumbersome to program as regex replacements or even more complex manipulation tasks).

It might well be fast enough on a modern machine, especially as it's a splay tree of lines, not characters, but it needs keeping in mind. I feel that it's sensible to expect it to support up to 10k cursors without undue slowdown (multiple-cursor.el currently breaks down at 500-700, depending on the length of the lines being edited).

[scymtym]

Much of the proposed functionality is available as of 55b41331f82ad963c0916dbce0dc3ac6e7321c8e. Suggestions for additional functionality or algorithmic improvements can be discussed in separate issues.