Multiple-cursors

Tue Aug 27 16:06:12 CEST 2013

Nikolai Weibull <now at disu.se> writes:

>> I've never used multiple-cursors which more or less implies that
>> there's no code in Evil to make both work together.
>
> It’s actually rather nice.  For those who haven’t seen it in action,
> here’s a screencast:
>
> http://emacsrocks.com/e13.html
>
>> And probably this is not so trivial (maybe in insert-state only, but
>> certainly not in normal-state).
>>
>> But of course, patches are welcome ;)
>
> I haven’t looked at the code, but my guess is that implementing this
> shouldn’t be too difficult.  The code should in many ways be similar
> to that handling visual block mode.
>
> Actually, multiple-cursors mode is really an extension of visual block
> mode, as visual block mode is more or less multiple-cursors mode
> limited to continuous lines anchored at a specific column.

I do not know for sure (I haven't looked into the code), but I assume
multiple-cursors does its magic by repeating each called command once
for each of the cursors, i.e. something like

(add-hook 'post-command-hook 
  (lambda () 
    (dolist (c cursors) 
      (save-excursion
        (call-interactively this-command)
        ...))))

However, Evil commands, in particular operators, are quite complex. When
an operator is called then another command, the motion, is called
intermediately, i.e. after the operator is started but before it is
finished (using a complex interactive code). But this implies that
reproducing an operator is not trivial. Evil needs several tricks in
order to record all commands correctly so that they can be repeated
later (the "dot" command).

However, you're right, Evil's block insertion is similar to what
multiple-cursors does and it is based on Evil's repeat-recording
mechanisms. So it is possibly easier to mimic multiple-cursors' features
on top of Evil's repeat system, which would be more robust and integrate
nicely in Evil's ecosystem -- but then one would not need
multiple-cursors anymore in Evil. This should not be too difficult
because all recording/repeating functionality is already there.

> I won’t have time to look at this right now, but if no one else has a
> better solution, I’ll certainly look at it sometime in September.

This would be nice.

Best regards,
Frank