4 ms·

Two things: Your comparison to anonymous functions is not apt. A language that implements higher order concepts like anonymous functions adds more power to th

Two things: 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.

detaro 9y ago
The claim wasn't that it makes macros less flexible. Just that the "ultimate feature" isn't very important to many people, and thus no reason to weigh macros over the (to some people) more intuitive workflow using multiple cursors. It's great that macros are a thing and have their benefits, I wouldn't want to remove them from editors, but "you don't need intuitive feature X, just use Y which is even more powerful instead" isn't a great message to users. (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?)
- carussell 9y ago
  The exact remark I'm responding to was this: > 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. 1. https://xkcd.com/974/ https://xkcd.com/974/
  - detaro 9y ago
    Fair enough, on re-reading I guess your interpretation of that line is just as likely as mine. 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.

detaro 9y ago

The claim wasn't that it makes macros less flexible. Just that the "ultimate feature" isn't very important to many people, and thus no reason to weigh macros over the (to some people) more intuitive workflow using multiple cursors. It's great that macros are a thing and have their benefits, I wouldn't want to remove them from editors, but "you don't need intuitive feature X, just use Y which is even more powerful instead" isn't a great message to users. (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?)

carussell 9y ago
The exact remark I'm responding to was this: > 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. 1. https://xkcd.com/974/ https://xkcd.com/974/
- detaro 9y ago
  Fair enough, on re-reading I guess your interpretation of that line is just as likely as mine. 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.