4 ms·

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 ma

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

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.