7 ms·

> Moving a block of code below another block of code takes 1 second in notepad++ while in vim you have to go V 10d x 13down P or something along those lines, fi

• jimmaswell 9y ago
  I didn't mean just blocks of code that would be recognized as a paragraph or are fully enclosed in brackets or anything like that. I mean moving some lines around possibly within the same function, which may or may not have multiple newlines between some of them, and have no lexically distinctive property aside from being the lines you want.
  • rco8786 9y ago
    It’s still just a few keystrokes.. 10dd 5j p. Take 10 lines, move down 5 lines, paste those 10 lines. With relative line numbers in the gutter there’s no counting involved either. The whole thing is faster than even just reaching for the mouse.
    • criddell 9y ago
      How far away is your mouse?
      • jonahx 9y ago
        As close as you like. Mouse movements are much more finicky than keyboard ones -- they require a physical precision (seeking, alignment, selection) that keyboard movements don't. And if you never leave the keyboard, you don't have to return to the keyboard to continue your typing. I'm confident even a moderately skilled touch typist familiar with vim would outperform someone switching to the mouse on average for these kinds of tasks.
        • geofft 9y ago
          I would be very interested to a) see this claim tested b) see if it makes a difference in productivity. (Most of what makes me slow at work is trying to understand technical problems, not trying to find parts of text in my editor.)
          • criddell 9y ago
            > Most of what makes me slow at work is trying to understand technical problems That's me too. I spend a lot of time each day reading and that's a lot of scrolling with my mouse and ctrl-clicking on works to jump to definitions or declarations. Text editing speed is definitely not a bottleneck for me.
          • jonahx 9y ago
            > I would be very interested to a) see this claim tested I would too. But I'd be willing to wager on the results beforehand. > b) see if it makes a difference in productivity. (Most of what makes me slow at work is trying to understand technical problems, not trying to find parts of text in my editor.) There's no doubt that things like understanding technical problems, avoiding procrastination, and many non-technical factors are the high-order bits of productivity. That said, the context of this conversation is text-editor optimization. Also, I think the true benefit of an optimized text editor isn't in raw time savings but in increased flow and just the joy of having a tool that feels like the extension of your mind, rather than something your mind works around.
            • criddell 9y ago
              > Also, I think the true benefit of an optimized text editor isn't in raw time savings but in increased flow and just the joy of having a tool that feels like the extension of your mind, rather than something your mind works around. I couldn't agree more. For me, that's working with a Logitech Anywhere MX mouse in Sublime Text. I imagine how I want the text on screen to be transformed and it just happens without conscious thought.
              • 9y ago
    • throwawayReply 9y ago
      But cursors don't imply mice. With cursors you just hold shift and use down-arrows to (visually) select the lines you want. Add in Ctrl and you can move word-boundaries, add home-end and you can do beginning/end lines / pages too. The whole thing is still quicker than vi but with the added benefits of getting much more visual feedback on what is happening and the ability to use the mouse to also quickly select things.
      • makapuf 9y ago
        Add to that by example sublime text Ctrl shift up to move the selection up one line. Really hope other editors would just take sublime key mappings
        • aenda 9y ago
          selecting something and hitting dP (potentially kdP) will do the same thing in vim
          • throwawayReply 9y ago
            In sublime text you don't need to select anything, ctrl+up/down will move the whole current line up/down.
      • smelterdemon 9y ago
        Sounds like Visual mode
  • adrianN 9y ago
    I'm not super good with movements myself, so I just use visual mode and the movements I know to select what I want. It doesn't take me longer than reaching for the mouse and moving it around most of the time.
  • hellofunk 9y ago
    I used to share your sentiment but kept going with vim for a year, and now I'm spoiled. Any time for some reason I am forced to use a GUI and a mouse, everything just feels so slow to me now.
    • btschaegg 9y ago
      Same here. Even if I'm forced to work with non-Vim tools (Visual Studio for example) using their often incomplete Vim-emulations makes lightyears of a difference. If I had to "criticize" one of Vim's concepts, it would be its way of overriding registers in very unintuitive situations, but I'm certain I'll get used to that, too. When you're aware of it, it's simple to avoid using "_ first. Edit: OTOH, selecting a piece of text and replacing it with p is quite irritating: The 0 register will still contain its original data, but " will contain the replaced text. I am not aware of how to disable this effect ("_p will paste from the black hole register, which doesn't help in this case).
  • mbag 9y ago
    Or switch to Visual Line mode (<shift>+v) to select desired lines and you don't need to count how many lines to delete/yank. Another useful visual mode is Visual Block (<ctrl>+v), for deleting/yanking, replacing block across multiple lines.
    • tgb 9y ago
      That's exactly what jimmaswell suggested he didn't like, though.
      • mbag 9y ago
        I see, I thought he had problem with counting line numbers to delete :)
  • jonahx 9y ago
    I'd make a few counterpoints there: 1. Even in those situations, I believe a veteran vim user would still beat someone using a mouse. 2. That said, the situation you describe is relatively rare: when coding you typically will be addressing blocks of text defined as functions; sharing an indent level ("ii" selects these); or otherwise selectable by vim in 2-3 keystrokes. 3. Even when that's not the case and the vim selection takes, say, 5 or 6 keystrokes, it has the advantage that your fingers never left the home row, so there is no wasted time "resetting." 4. Just as a tip: doing a "/" search for 2-3 characters after making your visual selection is typically enough to define your block, and will often be faster (and less of a cognitive distraction) than trying to eyeball or count the number of lines and doing a "10j" motion or similar.
    • stabbles 9y ago
      > sharing an indent level ("ii" selects these) That doesn't seem to work. Am I missing something?
      • jonahx 9y ago
        I'd forgotten that I get this feature from a plugin: https://github.com/michaeljsmith/vim-indent-object https://github.com/michaeljsmith/vim-indent-object
    • xyzzy_plugh 9y ago
      I've been eyeballing the number of lines (or characters) long enough that I am correct more often than not. Also, relative line numbering changed my life.
  • matthewaveryusa 9y ago
    put a marker at the begining of what you want to cut (mb) b is an arbitrary character but I use b becaues b = begin. find the end of the block with search, or jkl; or whatever. mark the end of the block (me) e is for end. now type `b, that will bring you back to the start. type v, that puts you in visual mode. type `e, that selects your text from begin to end. x to cut it. so all in all it's mb<search>me`bv`ex now if your say you can search your text faster with your mouse than with keystrokes you have a different problem: you don't know how to use the search features in vim efficiently.* I think it's nearly impossible to be faster with a mouse than a keyboard when it comes to search. *and yes, to be efficient at it there's a 2 month learning curve that pays dividends over the next 30 years of your programming career -- it's up to you if you think it's worth the investment or not. Use it or lose it, if you don't make an effort you'll stay at your local maximum.
    • jonahx 9y ago
      > so all in all it's mb<search>me`bv`ex why not just? v<search>x
      • matthewaveryusa 9y ago
        Just another suggestion. sometimes visual mode is overwhelming, or you don't want to be in it while your search for the end of the selection without being sure where it is. Another thing is if you start with line visual mode (V), and then you end up not wanting line selection the markers help you out -- it's a finer-grained set of commands that's a bit more flexible and a bit less efficient.
• davidkuhta 9y ago
  ^ Hey so for the novice to moderately experienced users, this actually works and is composed of three commands: dip => Operation - delete (cut) inner paragraph } => Movement - go to end of paragraph (the end of the paragraph following the one you deleted) p => Operation - paste (the paragraph cut using delete) Edit: Removed 'not sure why dip copies'; Thanks for the TIL PaulBGD_ ! Some other cool diX (delete inner X) commands here: http://vimdoc.sourceforge.net/htmldoc/motion.html#diw http://vimdoc.sourceforge.net/htmldoc/motion.html#diw
  • PaulBGD_ 9y ago
    dip copies because d isn't delete, it's cut.
    • davidkuhta 9y ago
      That makes sense, thanks.
    • fasquoika 9y ago
      Well, the mnemonic is delete, it just also puts the deleted text into your clipboard
      • ThatGeoGuy 9y ago
        Since we're talking about pedantry and how it relates to users learning and using vim, let's talk about clipboards. Your clipboard is the '+' register. Cutting or yanking text does not put it into the '+' register, but rather a specified default local register (is it normally 0? Somebody feel free to correct me here). As a consequence, if you delete or yank some text, it doesn't go to the clipboard. If you really want it to go to your clipboard, specify '+' as the default register or call di"+p in place of dip. This naturally confuses beginners because the concept of registers is completely foreign to other editors. Emacs can provide similar functionality, but by that point Vim is no longer in "weird" mode compared to what you know. We do a lot of simplification when talking about Vim, but small points like this can be immensely confusing for people who just want something to behave the way they're used to.
• geofft 9y ago
  > it's not really fair to criticize something because you don't know how to use it well yet I don't see any criticizing, just "it doesn't work as well for me," which I think is entirely fair. In particular, it seems like 'jimmaswell prefers an editor where you think of blocks of code as "I can see this on the screen" than "up to the end of the current curly brace," which seems like a legitimate difference in mental processing styles, not a consequence of lack of learning. I've been using vim as my only code editor for probably 10 years now, and dip}p is foreign to me. I'd do it by using /{ to search for the beginning, using Ctrl-V /} or /^} or something to search for the end, then using d and searching again for the place I want to insert it with p. (Also, I think { and } don't work if you're using Python, whereas "I as a human can understand the structure of this code and identify the beginning and end of functions, which I already do because I'm literally writing code in this language" is portable between languages.)
  • jonahx 9y ago
    > I don't see any criticizing, just "it doesn't work as well for me," which I think is entirely fair. I had no problem with his tone. But he's very much making a statement about a technical problem he has with vim, and which isn't well-founded. > In particular, it seems like 'jimmaswell prefers an editor where you think of blocks of code as "I can see this on the screen" than "up to the end of the current curly brace," which seems like a legitimate difference in mental processing styles, not a consequence of lack of learning. There is nothing about vim that impedes a visual mental processing style. I constantly look at a place I want to select and then jump there using any number of methods -- the easymotion plugin is ideal for this. > (Also, I think { and } don't work if you're using Python, whereas "I as a human can understand the structure of this code and identify the beginning and end of functions, which I already do because I'm literally writing code in this language" is portable between languages.) Again, even vanilla vim performs better here than a mouse. But you should really have custom text objects installed for any language you work in regularly. Here's one for python: https://github.com/bps/vim-textobj-python https://github.com/bps/vim-textobj-python
    • ethagnawl 9y ago
      Thanks for plugging easymotion. I regularly use a similar feature provided by the VimFx Firefox add-on, but never bothered to look for a way to move similarly inside Vim itself.
• pvg 9y ago
  which would be pure muscle memory to an experienced vim user As selecting some text with a mouse would be for anyone who's ever edited text with a computer. It's hard to see this kind of argument as more than a statement that learning arcana can be enjoyable. It's true, but then you might as well be learning Rust or writing a tutorial on understanding monad tutorials.
• auggierose 9y ago
  What if your block isn't denoted by curly braces but just indentation?