> get more comfortable with your editor’s macro feature. If your editor doesn’t have a good macro feature, get a new editor.
They also link to an essay[0] pointing out numerous ways in which multiple cursors don't play well with advanced editor features (using Vim for the demonstration but the point likely works just as well for Emacs).
Sure you can also take the inverse tack and switch to an editor implemented in such a way that multiple cursors is efficient, but… is multiple cursors really the feature you want to stop at?
[0] https://medium.com/@schtoeffel/you-don-t-need-more-than-one-...
> The ultimate feature that comes with vim is, that you can edit and save these macros for your next vim session and even add a key mapping.
They almost entirely miss the point of the feature. 99% of the time when you're editing with multiple cursors, you're doing a unique thing which would be meaningless outside the context of where you're doing it. The ability to save the macro misinterprets the flexibility to do exactly what is needed at the moment.
Your comparison to anonymous functions is not apt. A language that implements higher order concepts like anonymous functions adds more power to the language. But on the spectrum of power, multiple cursors are not a more powerful form of macros. Macros—Vim's, at least—are higher order than multiple cursors. (Note that when I say "macros" here, I'm going along with the premise of the Medium article where the ability to replay the last edit using `.` is also considered macro use.)
Second, the ability to save a macro doesn't make macros less flexible. It's not as if you have to pay for it whether you use it or not. If you don't want to save it, then don't; but it's there if you want the option.
(Something I've been missing in this discussion: are multi-cursors to slow for users in practice, or is this technically slower/"less efficient"?)
(and for the side-discussion about the function example: Doesn't the extra power in the function case comes from being able to pass and dynamically create functions, not from the fact that they are anonymous? E.g. in Python, lambda functions really just save a few characters over using local named functions? Am I missing something?)
> The ability to save the macro misinterprets the flexibility to do exactly what is needed at the moment.
This makes it sound like a +1 for multiple cursors and and a plus null for macros/replay. You could argue that the wording is just so and doesn't actually claim that macros are less flexible. But the reality of the situation is that macros are +1 and multiple cursors is plus null, and the gestalt of comment I responded to doesn't convey that. That is, in all the cases where multiple cursors shine, Vim's native features are, at worst, on equal footing, and there's a non-zero count of cases where the inverse is not true. However, someone who hears the argument in the message I responded to might come away feeling that the opposite is true.
> "you don't need intuitive feature X, just use Y which is even more powerful instead" isn't a great message to users.
This, too, sounds like a crafted message—that Vim's native approach is missing something, and that advocating for e.g. repeat instead multiple cursors is shortsighted (somewhat reminiscent of [1]). The implication tends to be that the alternative might be more powerful but less intuitive or require orthogonal thinking. And there are cases in computing like that. Plenty. But using repeat instead of multiple cursors is not one of them.
I still argue that macros are missing something UX wise. It's a matter of preference which style you like better for specific problems, and I haven't seen a good argument for why only one of the two should be present. I don't think the fact that macros can fulfill the same function is a good argument. Them being more powerful IMHO isn't either, it just means that when multi-cursor editing fails someone preferring it, they still have the option to use macros then.
I haven't actually tried multi-cursor editing in emacs - if it is unusably/annoyingly slow, then the article would be interesting as an explanation for why that's the case, but its failing to establish that context.
If it's not, it's still interesting from a theoretical perspective. I think it shouldn't argue against multi-cursor editing the way it does.
Presenting the option of using a macro is fine, explaining the benefits of it is great, dismissing multi-cursor editing as
> tacky and modern
is totally unnecessary. And unrelated to an article about implementation details. Write "Why you should consider learning about macros", make a case for them that's unrelated to "our datastructure doesn't like the alternative as much".
EDIT: to address the quoting: It wasn't my intention to look like I'm making up quotes, I need to think about a different way of marking these up it seems. I try to put actual quotes on new lines.
When you record a macro, you need to be careful to encode commands that will work well wherever you apply it. That means skipping forward by a word rather than a fixed number of characters, sometimes doing fiddly operations around word and whitespace boundaries to make sure the cursor is in the expected position for the next step. When multiple cursors are used to emulate macros, you get a wysiwyg experience, rather than "programming" the cursor and finding out later during playback that it did the wrong thing.
Multiple cursors are also used as a replacement for text search and replace; sometimes the operation could be performed using a symbolic rename, sometimes it could be done by search and replace with live preview, but not when you want to skip some instances.
Probably 95% of my personal use of multiple cursors is for local refactoring, e.g. switching out a hash for an object or vice versa, where I want to change 'foo.bar' to 'foo[:bar]', but sometimes (electively) 'foo.fetch(:bar)'. Multiple cursors let me do both the selection and the editing in a wysiwyg fashion, where neither macros (typically with a 'find next' operation recorded last) nor a complex search and replace with capture group and interactive replacement are nearly as pleasant.
FWIW, for many years I used Borland IDEs and almost the only tool available for complex manipulation was keyboard macro record and playback (I spent probably 15 years only using keyboard macros). These days, though, the combination of synchronous editing (iedit mode in emacs) and multiple cursors have almost completely replaced my macro usage with much more usability due to the live feedback.
The Medium article about multiple cursors was from a Vim-centric perspective (in contrast to the linked article here, which was Emacs-focused). And in Vim, you'd do this with `n` and `.`. For example, `n.n.nn.` means, "change the second occurrence, too, and the third, but not the fourth, and do replace the fifth".
Multiple cursors is no faster, and since you mentioned the benefit of not needing to carefully plan ahead (which I also think is important[1), I'll leave you with the observation that multiple cursors requires more planning than `.`. With `.`, the following thought process is valid:
"Let's change this. Oh! And do these other ones, too."
Compare to multiple cursors, where you have to don't have to plan as carefully as a recorded macro, but you still have to do some planning, because you have to start out knowing that you're going to change multiple things and then marking them before you make any change.
So the spectrum looks like:
# Recorded macros—requires lots of careful planning
# Multiple cursors—requires little planning
# Replay (`.`)—requires no planning at all; can fit your stream of consciousness
Hm, it strikes me that it might be a cool feature to interactively select as many of the last few commands you gave as you like, and copy them to a macro register. It seems like it wouldn't be too hard to implement, seeing as the commands you make are already stored in the undo tree.
People like multi-cursors because their behavior is very stable and obvious. Macros have very unpredictable behavior except on lines that precisely conform to the shape of line you used to specify them.
And buffer narrowing/widening isn't a solution. You can specifically play the macro over cursor lines (it is a "good practice" to C-a at the start of a macro to help with this), but it's many more keystrokes.
It may be "all hat and no cattle" as the author says, but I have uses for hats and I've got no facilities to keep or slaughter cattle.
Control-x ) stops recording a macro
Control-x e replays the macro
They're no more obscure than the rest of emacs (which isn't a great starting point!) but everything comes down to keybindings in any text editor, you can map them to any key you want.
Cool, you can start and record a macro. What does the temp macro do on this line? On a different line? Does your undo stack flip over or through the macro? How do you run the macro on lines with a specific suffix?
Because macros inherently make a big blob of actions and turn them into a single action, they're inherently more obscure than multiple cursors.
The funny part is of course that macros are dictated in emacs, not programmed. So what the multi-line cursor is doing is essentially showing you the results of a macro and letting you interactively work with it visually rather than deny you that option.
Macros have uses, but Swift multi-line editing is by no means their strong suit.
IMO, the features you advocate instead of multiple cursors don't play well with a fairly large fraction of users.
So, do you get rid of those users, or do you adjust your program to them, so they get a subset of the power of macros that they can happily use?
There isn't a single mainstream OS that supports having multiple mouse cursors that I know of, and even if it did, not a single program expects it either - most would break. The closest we have is on-line editors that can have multiple users like Google Docs, and that's not single screen.
And you may be thinking "yeah but why?" and I wouldn't blame you, but that's just because you're not aware of how how much our current input devices limit us and how they are based on a flawed model of handedness.
Yves Guiard proposed a model in 1988 that argues the dominant/recessive model of handedness is wrong: instead, we constantly perform complicated asymmetrical tasks, with one "coarse" reference-frame hand and a fine-tuned "zoomed-in" hand (the latter being considered the dominant one)[0]. Later research has only backed this up (note that the linked paper has over a thousand citations).
When keeping this asymmetrical model in mind designing our input, things tend to just "feel" right. I guarantee you that the best two-handed input methods you use all follow this principle: even if not applied consciously, any two-handed interfaces converges to it. Simple case-in-point: remember 3D shooters before WASD + mouse? WASD = reference frame hand, mouse = fine-tuned input hand. Gamers just intuitively discovered this on their own. In fact, look at button placement on gamepads in general: movement ("frame of reference") on the left, action buttons on the right.
Bill Buxton[1][2][3] did really cool experiments with these ideas and then... well, nearly nothing. And I really believe the main reason is a lack of technical freedom to experiment: even if someone does manage come up with a wonderful intuitive, fluid bimanual interface that isn't limited to a keyboard, a mouse and maybe a touch-screen, who is going to be able to use it on their laptops or desktops?
I'd like to experiment and the fundamental requirements to do even that are missing. Even multi-touch is barely going to help: you cannot tell which hand belongs to which touch-point.
[0] https://www.ncbi.nlm.nih.gov/pubmed/15136274
[1] https://www.billbuxton.com/2hands.html, video: https://www.youtube.com/watch?v=w0c1Xg9lERY
I would imagine that a touch scroll pad like in the linked video would be a useful thing to have on the left hand side of a keyboard. I could use it to navigate through a document quickly and use the mouse to pick my target.
Games and input devices for games also always design around bimanual input, even if rarely consciously.
Side-track: something almost nobody noticed when the Wii came out is that it's wiimote/nunchuck setup works both for right- and left-handed people. I'm left-handed and I automatically switched to a left-handed input method for my games without even thinking, for the first time in my life! I didn't even realise this until a few months in myself!
And yes, I completely agree with you! Something I forgot to mention is that for certain types of tasks, this kind of input lowers the mental burden for the user (something that Buxton showed in his papers).
If we turn your idea around: laptops come with a trackpad by default. If only OSes would allow for distinguishing between it and and external mouse (for example), then we could already cheaply and easily experiment with this on our laptops!