6 ms·

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 arou

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.
        zastavka 9y ago
        Anything special about that particular mouse that makes it good for editing with ST?
        criddell 9y ago
        No. It's just the mouse I've been using for a long time now. It's small, I'm used to how it tracks and accelerates, it fits my hand, and you can disengage the click mechanism on the scroll wheel to spin it freely. My big complaint is that the buttons eventually start to fail. Single clicks will sometimes register as double clicks and click-drag operations start to drop early.
    - chucky_z 9y ago
      Have you tried a trackball mouse? That was the magic 'ah-ha' moment for me. I haven't used a normal mouse (at work) in probably 6 years or so. I find in speed it is trackball + kb > kb-only > normal mouse + kb.
- 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.

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.
        zastavka 9y ago
        Anything special about that particular mouse that makes it good for editing with ST?
        criddell 9y ago
        No. It's just the mouse I've been using for a long time now. It's small, I'm used to how it tracks and accelerates, it fits my hand, and you can disengage the click mechanism on the scroll wheel to spin it freely. My big complaint is that the buttons eventually start to fail. Single clicks will sometimes register as double clicks and click-drag operations start to drop early.
  - chucky_z 9y ago
    Have you tried a trackball mouse? That was the magic 'ah-ha' moment for me. I haven't used a normal mouse (at work) in probably 6 years or so. I find in speed it is trackball + kb > kb-only > normal mouse + kb.
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.