Integration of multiple cursors into the vi(m) workflow

[erf]

It seems multiple cursors are better supported than visual mode, so i suggest Ctrl-N stay in normal mode so you can do normal operations / movements and repeat them with dot.

[martanne]

The integration of multiple cursors into the vi(m) workflow needs some more design work (for which I do not have the time right now), at this point in time it is more a proof of concept ...

[erf]

I understand. But ctrl-n creates multiple cursors anyway, i just want it to stay in normal mode since that mode is better supported with multiple cursors.

[erf]

Add number, for exampe 3 before CTRL-j to add 3 cursors down

[erf]

Now i have to press ESC two times to exit to normal mode after mulicursor insert

[TieDyedDevil]

re: "Now i have to press ESC two times to exit to normal mode after mulicursor insert"

I believe that's expected. The first ESC exits insert mode; the second exits multicursor mode.

[erf]

@TieDyedDevil You are right, don't know what i was thinking..

[martanne]

The : commands should also be changed to take multiple cursors/selections into account.

[erf]

Now cursors are added to lines with already existing cursors - instead: CTRL-J add cursor to max_y(cursors) + 1 CTRL-K add cursor to min_y(cursors) - 1

Shrink/Grow cursors with CTRL-ALT-k / CTRL-ALT-j ?

[martanne]

I think structural regular expressions will integrate nicely with multiple selections. See this mailing list thread for some general ideas. Interested people can try out the sam branch, the README contains pointers to documents describing the command language.

A few basic examples for those unfamiliar with sam's command language:

:sam x/foo

e_x_tracts/selects all occurrences of foo

:sam x/foo/c/bar

_c_hanges all foo to bar

:sam x/foo/{i/-/a/-/}

_i_nserts a - before and _a_ppends a - after every match of foo

:sam x g/foo/ x/bar/ c/baz/

e_x_tracts all lines (default if no regex is given for x), keeps those lines matching foo and within those extracts all bar which are then changed to baz.

For more take a look at the documents linked from the README. There are likely still some bugs left, but overall the concept seems promising.

[erf]

Would it be an idea to move the primary cursor to the top / bottom with <C-k> and <C-j> before creating a new cursor ? Then you would always create a cursor on a new line and not overlap ?

[martanne]

The problem with this is that vis currently does not maintain an ordering relation among its cursors.

As noted in the commit message of d268609511dc77e1acbd3885642b82751d32bccc that <C-u> and <C-d> "work" is mostly by accident. They move to the previous/next cursor based on the order they were created not their current location in the file.

That can for example be observed by creating a couple of cursors with <C-k>, in this case the effect of <C-u> and <C-d> is reversed (because the cursors were created from bottom to top).

It happens to work for the common case because cursors are usually created in a "top-down" manner i.e. from the start of the file towards the end. This is the case with <C-n> , I and A in visual mode as well as for the new :sam x/ command.

To conclude we currently can't easily move the primary cursor to the top/bottom, because we do not know the relative placements of cursors among each other. Maintaining an ordering among cursors would allow a few other possibly useful operations such as selection rotation or column alignment (currently <S-Tab> in insert/replace mode won't work as expected when there are multiple cursors on the same line). For these reasons it might get implemented at some point.

Independent of that I think usage of <C-k> and <C-j> should be minimized. It is generally preferable to create cursors on multiple lines from visual mode. For example I frequently use va<Tab> to select a region with the same indentation, then create a cursor on every line with I move to the desired place with f<some-char> and perform the editing. In the future the structural regular expression support will allow even more powerful modifications.

For now creating overlapped cursors is considered a "user error".

[erf]

Thanks for the explanation, however since each cursor have position, would it not be easy to create a function that gets the max/min position or order given all cursors?

[martanne]

Yes of course it would be easy to do so, in fact the alignment functions already do something similar. However it is not clear that the behavior you propose is what we want. With the :sam commands you will get many selections all over the text, if you then place the primary cursor somewhere in the "middle" of those and press Ctrl-j or Ctrl-k it would create a cursor in a totally unrelated text region.

[erf]

I understand and think the :sam commands will be powerful, but i hope the Ctrl-j and Ctrl-k won't go away as they are fast to use when you just want to change a few lines without leaving normal mode.

[martanne]

Ctrl-Meta-j and Ctrl-Meta-k should do what you initially wanted. Also these commands should now respect a count. See the README for details.

[erf]

Thanks! Would it be an idea if you press C-j and there already exist a cursor there, to try to create a new cursor on the next line untill a non-cursor was found? That might be more useful than moving the cursor up/down, as you already are able to do with C-d and C-u. Not sure if there are many use-cases for this, but you could implement C-h and C-l to create cursors on the next/prev char. Also when creating multiple cursors from selected lines, trying to maintain the current column position seems logical.

[martanne]

On the sam branch I tried to unify the traditional vi(m) and sam command line syntax. That is structural regular expression commands need no longer be prefixed with :sam.

There are likely still some bugs left, but I have now switched to the sam branch as my default editor. I would appreciate it, if a few interested people would also give it a try. Regressions from a vi user perspective would be welcome. Thanks.

[martanne]

Here is a asciicast showing some of the recent features:

[erf]

I liked that in the previous demo you could see all the key presses - i guess i'm just curious how to switch the selections at 0:54 ..

[martanne]

That is selection rotation using + and -, respectively.

Also I agree asciinema would be way more useful if it had an option to display key overlays. The feature was requested many times (e.g. https://github.com/asciinema/asciinema/issues/105, https://github.com/asciinema/asciinema.org/issues/84 and all the referenced issues), but it seems like the main developer has other priorities.

[erf]

I think the multiple cursors solution with sam is working great and that we should close this issue now and rather open a new more specific issue if/when needed.