5 votes

Gap buffers are not optimized for multiple cursors

3 comments

  1. [3]
    tesseractcat
    Link
    Seems like two weird arguments meshed into one. The first argument is that multiple cursors aren't actually useful, and can be replaced with features like visual-block, search and replace, or...

    Seems like two weird arguments meshed into one. The first argument is that multiple cursors aren't actually useful, and can be replaced with features like visual-block, search and replace, or macros. I think this argument is subjective, and I personally disagree.

    The second argument is that multiple cursors aren't performant, which seems somewhat strange to me. Computers nowadays are incredibly fast, and most code/text files aren't that big. Why should we then base our editing paradigm on what is most performant for the computer? I'd rather base my editing on what's most intuitive and fluid, even if it takes up a few more cycles.

    7 votes
    1. hungariantoast
      (edited )
      Link Parent
      So I just ran into an issue where mutli-cursor editing fails hard in both VSCode and Emacs. I'm using VSCode's native multi-cursor feature, and the multiple-cursors.el package for Emacs. I have a...

      So I just ran into an issue where mutli-cursor editing fails hard in both VSCode and Emacs.

      I'm using VSCode's native multi-cursor feature, and the multiple-cursors.el package for Emacs.

      I have a list of about thirteen thousand links that I want my computer to, one-by-one, download "overnight" using SingleFile.

      VSCode has a 10,000-cursor limit for editing, but I tried it anyway. Inserting the 411-character SingleFile command before each URL in the file was fast-ish, but adding 10,000 new lines to add another command after each SingleFile command... never finished. I waited twenty minutes just to be sure.

      The Emacs package worked a bit faster than VSCode at adding the SingleFile command before each URL, and does not have a 10,000-cursor limit, but also completely failed to add newlines to the file.

      In the end, I just ran a quick set of Emacs commands to prepend the SingleFile command to each line, and added two new lines and the second command at the end of each line. It took less than thirty seconds without using multi-cursor.

      Multi-cursor editing is great for quick and small edits. I used it all the time when VSCode was my editor of choice, and it was one of the first things I set up in Emacs.

      But for silly large stuff like this, it has massive performance issues. So I'd say it's still important to know how to use regexp, macros, and other fancy tools provided by the editor.

      (And yes, SingleFile has a command to batch process URLs from a text file. For some reason running the program like that results in more URLs failing to be downloaded than the way I am doing it.)

      (Sublime has multi-cusor editing, right? Does it have the same performance issues?)

      This comment brought you by a lack of sleep, slight frustration, and some amusement. Let me know if you have any questions.


      Useful links:

      https://stackoverflow.com/questions/613022/how-to-replace-a-character-with-a-newline-in-emacs
      https://stackoverflow.com/questions/4870704/appending-characters-to-the-end-of-each-line-in-emacs
      https://emacs.stackexchange.com/questions/11/how-to-add-a-prefix-to-every-line

      3 votes
    2. Moonchild
      Link Parent
      It's not even that multiple cursors are slow; it's that a particular technique for implementing a text editor buffer can't implement multiple cursors performantly. (Though, fwiw, I do agree that...

      It's not even that multiple cursors are slow; it's that a particular technique for implementing a text editor buffer can't implement multiple cursors performantly. (Though, fwiw, I do agree that multiple cursors are the wrong editing model.)

      3 votes