20 ms·

I've used vim quite a bit but it still never beat GUI editors for me. The lack of a mouse cursor was always a pain point - for example simple copy/pastes take n

• siissussjskk 9y ago
  Maybe learn how to grok vim?
  • lighthazard 9y ago
    How do I select Lines 3, 16, 39, 50, 230, 420, 1302, and 2300 at random columns of my needs? With a mouse, I can cntrl/cmd + click the line I am interested in, wherever I am interested, and do any manipulation I want. Can VIM do this easily? I've never tried.
    • bananicorn 9y ago
      Maybe you're looking for visual block mode?[0] Or the multi-cursor plugin[1]? I haven't tried the latter, ut I really like visual block mode for certain things. It's amazing how much new stuff I learn about vim every day... And I'm nowhere near done :) [0]https://stackoverflow.com/questions/21806168/vim-use-ctrl-q-for-visual-block-mode-in-vim-gnome#21808952 https://stackoverflow.com/questions/21806168/vim-use-ctrl-q-... [1]https://github.com/terryma/vim-multiple-cursors https://github.com/terryma/vim-multiple-cursors
    • aoloe 9y ago
      it depends on what you want to do... but my general reflex is: - go to line 3 - start recording a temporary macro ("qq" in my habits) - do the editing - stop the macro ("q") - go to the line 16 with 16gg and reply the macro with @q - 39gg@q - 50gg@q - ...
      • bananicorn 9y ago
        this. Macros are something I've never used in other editors, but in vim they're simply... fun to use. Well, if used for the right purpose.
    • deleted 9y ago
      [deleted]
    • dredmorbius 9y ago
      And, in all earnestness: why are you doing that? Is there something about those specific line numbers intrinsically? Is there a pattern or specific text on those lines? Is there a relationship to surrounding text, above or below? The great thing about vim, or a set of similar tools (ed, ex, sed, awk, perl, cut) is that you can address the text in terms of the text itself. Search by text or regex, move within a line or between lines. Replace text or modify elements, preserving some and changing others. Or, if I know in advance that I've got to deal with the 8 specific lines mentioned but without otherwise addressible context: 3G <edit stuff> 16G <edit stuff> ... 2300G <edit stuff>. That's not elegant, but it's doable and fast.
      • lighthazard 9y ago
        Line numbers were irrelevant, just a set of random numbers. There is no pattern to the text (say it's a set of words that needs to be edited to become the same). I guess this is more related to working with large blocks of text rather than code. Someone mentioned macros, I'm going to give that shot.
        • dredmorbius 9y ago
          What's the characteristc of the text and how do you identify it? Again, search, paragraph and sentence navigation, and word nav are intrinsic to vim, and fast. If you know what you're looking for, "/<pattern>" and you're there. With incremental search ("set ic" in your ~/.vimrc) thats often a very few keystrokes.
    • ATsch 9y ago
      What are you trying to accomplish with this? If you are trying to replace multiple cursors, the approach would be very different. What I'd do is record a macro for the edit on one line into q, and then apply it to all relevant lines with a regex, e.g. g/regex/norm @q
  • mercer 9y ago
    Surely you'd agree that a mouse as an interface can provide benefit even in the context of a text editor?
    • ATsch 9y ago
      Sure, but the question is if the physical and mental context-switch is worth this benefit. I'd say that in editors with a sufficiently expressive keyboard interface like vim, it is not. One thing I still find myself doing in vim is using the scroll wheel. Browsing and editing is a context switch anyway and I think scroll wheels express scrolling a lot better than keyboards ever can.
      • mercer 9y ago
        Fair enough. I would definitely err on the side of vim when it comes to the benefits of staying within vim's 'mental model', because I do agree the context-switch does matter. Furthermore, the fact that all my vim-context keypresses can be stored as a 'macro' in itself has provided enough of a productivity increase to make it all worth it. And this is even the case in less-than-perfect vim emulators. And I do agree that for some things, scrolling and perhaps 'exploring' in general being a big one, a mouse can be worth the context switch.
    • shangxiao 9y ago
      siisussjsk might've been referring to doing a quick check to see if vim supports mouse as an interface… which it does.
• delta1 9y ago
  In {G|Mac}Vim you can also use the mouse cursor and selection.
• et1337 9y ago
  I feel the exact opposite. Reaching for the mouse and aiming the cursor takes forever. I almost never use number prefixes like "10d" for the same reason you dislike them. There are so many other options. } to skip to the bottom of the paragraph, % to skip to the end of the block, H/M/L to target a position on screen, / or * to navigate by searching, Ctrl-D to scroll down half a screen... Also try VsVim for vim key bindings inside Visual Studio. Or Sublime with vim bindings on instead of notepad++. :)
• bananicorn 9y ago
  There's a bunch of things you could try, btw: First off, vim has a GUI version where you can use the mouse (and in some terminal emulators you can too - for example st[0]) Secondly, did you try using splits (horizontal and vertical is possible, you practically have a sort of WM inside vim) or maybe you prefer the tabs-approach to things (even though the purpose of tabs is a different one, but you can bend it to your will so it works kinda like in notepad++) Also, relative line numbers really help me with the vertical navigation - you practically have the number you need to type at the start of the line (and your current line can have the actual line number, if :set nu is active) [0]https://st.suckless.org/ https://st.suckless.org/
• Rainymood 9y ago
  >I've used vim quite a bit >pgup/pgdn and arrow key Then you should start learning how to use Vim, properly ;). Start from the basics, work your way up. From your post it is painfully obvious that you don't really use Vim to it's fullest potential. Vim requires a completely different way of thinking than regular text editors, and, it requires time to learn. Only use up down with kj for fine movements. Large movements happen with gg, G, preset marks, and <C-d> and <C-u> which are half screens down and up for me respectively. That covers vertical movement. Most of my horizontal movement is done with either f or vim-seek (which is like f but takes 2 characters!)
  • sevensor 9y ago
    Also very useful is setting "number" and using :123 to jump to line 123. This helps the most with compiler errors, but it can also help if you've got a lot of lines on the screen.
    • nothrabannosir 9y ago
      123G (saves you one “return”, which is an annoying key.)
      • mythrwy 9y ago
        123gg saves a shift :)
• Moogs 9y ago
  Vim does have support for mouse usage (depending on the terminal)[0]. You can add the following to your config: set mouse=a At that point you can quickly select text, hit "d" to cut it, click where you want it and hit p [0] http://vimdoc.sourceforge.net/htmldoc/options.html#%27mouse%27 http://vimdoc.sourceforge.net/htmldoc/options.html#%27mouse%...
  • jimmaswell 9y ago
    I knew about this but I assumed it couldn't be done through ssh/putty.
    • exDM69 9y ago
      Not sure about putty but it definitely works over SSH depending on your terminal emulator.
    • geofft 9y ago
      It works through PuTTY, and moreover it's the default config in Debian 9, which I find sort of annoying because I'm used to using the mouse in PuTTY for copy/paste. But it does work smoothly (including through a screen session and through ssh to other machines).
    • shangxiao 9y ago
      Perhaps you should add an [edit] to your original post seeing as it's nabbed top spot and spawning several threads about lack of cursor support?
    • jstimpfle 9y ago
      It works independently of transmission method since the mouse clicks are simply translated into "keyboard presses", i.e. encoded to stdin as escape sequences. It's a single stream. Of course, the terminal emulator must play nice with the windowing environment and translate mouse events correctly.
    • kazinator 9y ago
      What cannot be used through SSH/PuTTY is the IDE that you're comparing text-only Vim to.
• sevensor 9y ago
  I think, because you're used to it, you're under-estimating the cognitive overhead of using the mouse. It also sounds like you've bought into some of the worst kind of vim evangelism, the kind that says effective vim users never hit j repeatedly to move between lines. Granted, it's not the best, but if you're moving only ten lines, V followed by repeated j takes basically no thought to create the selection. If it really bothers you, v followed by / will extend a selection to the match. I find that I mostly use / and ? to move around. In that context, setting hlsearch and incsearch might be helpful. You might also want to use code folding, especially if moving blocks of code around is something you do a lot of. If you delete a fold in vim, the whole fold goes into the paste buffer.
  • mercer 9y ago
    What's the cognitive overhead? I'm a huge vim weenie and a pretty fast typist, but I'd never argue that the mouse is obsolete when compared to vim. For example, I've played FPS games where I had to target something the size of < 10 pixels, in less than a second, and the need to move my mouse from one end of the mouse pad to the other. Basically, the mouse and (in most cases) cursor are barely separate from my body when it comes to pointing at things on the screen. So when I need to put the cursor somewhere, I still find that using the mouse can be much faster than any vim key combination. While I do agree that the 'context switch' from keyboard to mouse matters, I still find using a mouse/trackpad worth the relative effort often enough that 'pure' keyboard vim is a degradation in experience.
    • dredmorbius 9y ago
      Reaquiring the cursor is an issue for me on systems that "helpfully" make vim mouse (or touchscreen) sensitive. The cursor's where I left it, damnit. Don't move it and force me to put it back. There are times when directly pointing to screen elements is useful. Working with text I almost always find it gets in the way
    • sevensor 9y ago
      I don't think the mouse is obsolete, just that it's an obstruction when it comes to editing text. Vim, emacs, and my current favorite, kakoune, all give you a rich language for talking to the computer about how you want your text to be arranged. The mouse doesn't speak that language. It requires you to switch from thinking about text as text to thinking about it as a pixel target. That may only feel natural if you play a lot of FPS games.
• cup-of-tea 9y ago
  Both gvim and graphical emacs support mouse. But if you use it you're doing it wrong anyway. You're using your boot instead of a hammer because you couldn't figure out which end was the handle.
• garou 9y ago
  I am not going to say "ViM is better". Are you intended to keep using vim to edit these remote config files? May it be unnecessary, but if you want to try read this article to figure out how make these things faster using vim. But IMHO if you are just going for it, there's no reason to learn vim. It is a long path indeed, but wort it.
  • jimmaswell 9y ago
    If I'm in an ssh shell and I want to edit a file, yes, I'll use vim. I've also done some coding in vim which is what I was mainly talking about.
    • garou 9y ago
      It is quite annoying that you get so frustrated about not having enough guts to spend learning vim and instead wanna discount on who likes vim and spent time learning. This kind of 'flame wars' is cancerous. grab your mouse and close this window instead of cmd/ctrl+w, good bye.
      • jimmaswell 9y ago
        You're blowing this out of proportion. Read it again, I didn't discount anyone. All I said was I found one thing more efficient for myself than something else.
• jonahx 9y ago
  > 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, figuring out exactly what numbers to use there probably takes more than 1 second alone. dip}p which would be pure muscle memory to an experienced vim user, and certainly faster than doing it with a mouse. Vim isn't for everyone, but I mean, it's not really fair to criticize something because you don't know how to use it well yet (though complaining about the learning curve would be reasonable)...
  • 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.
• stanmancan 9y ago
  The whole argument of “wasting time” reaching for the mouse has never made sense to me. In a decade of programming its never been a bottleneck for me. Maybe I’m an outlier here but the whole thinking, planning, and experimenting takes way longer than my hands can move.
  • oblio 9y ago
    You're not an outlier... The only time when editing takes longer than thinking is when you're processing textual data dump files in their various shapes and forms (logs, database dumps as SQL, etc.). For code thinking definitely takes longer than actually editing :)
  • swiley 9y ago
    It's not about wasting time, pointing devices are less precise which means they demand more attention and are less flexible.
    • metaobject 9y ago
      Going with your theory, I'd say that pointing devices are more precise which means they require more brain-CPU cycles to operate ... pixel-space is large and you must position it within some delta of the target widget you're trying to use. Whereas in emacs, say, it's a quick "C-x o" to change to the next/other buffer.
      • swiley 9y ago
        Right, they're more precise and less accurate.
  • jeromenerf 9y ago
    I think it depends on the task at hand, whether you are jumping around or focused on a long piece; exploring or debugging ... Anyway, not everything takes place in the editor. "The acme user interface for programmers" (http://acme.cat-v.org/ http://acme.cat-v.org/) is a good inspiration. It focuses on mouse usage and shows how most systems are as nicely integrated as they could be. I have hacked together a setup that mimicks acme using a tiling wm, vim (and its amazing remote features), a plumber and a terminal that can send the current selection to the plumber. This way I use vim as I like but I can send it some path:line:col from anywhere with a right click.
• swiley 9y ago
  vim, tmux, and ssh have gpm support.
• BatFastard 9y ago
  Wow, shall we argue over whether tabs or spaces are better too? And after we solve that we can figure out how many angels can dance on the head of a pin!
  • metaobject 9y ago
    Btw, the answer is "spaces" because tabs can be interpreted differently from editor to editor. To take it a step further, its 4-space indents. I've seen code where people pull off 2-spaces, but it gets crowded failrly quickly.
    • albedoa 9y ago
      > tabs can be interpreted differently from editor to editor. You should ask a tabs advocate what they think the primary feature of tabs is :)
• rwallace 9y ago
  How do you get moving a block of code to take one second in notepad++? I don't know of a way to get it to take less than a few seconds, but maybe I'm missing something.
• shadowfiend 9y ago
  I'd say two things here: - Recent vim in terminal (and vim in a GUI container like gvim or MacVim) supports mouse interactions. For example, in macOS's Terminal.app, View -> Allow Mouse Reporting will send mouse events to vim, which will allow you to scroll with your touch pad, select with your mouse, etc. - I think there is definitely a curve to learning many of the movement commands that vim provides to become fully efficient at moving, say, a block of code. When moving blocks of code, I most frequently use % (which jumps to the matching brace/bracket/paren) or } (which jumps to the next blank line). I agree that it sometimes feels like there's an analysis step in vim interactions that can feel like it's slowing things down rather than speeding them up. In my experience, much of that calms down after you've been doing it a while. But, that doesn't mean it's worth the investment---I think that depends on the person. I seem to editor-hop every 2-4 years. I generally end up coming back to vim for long stretches, but I've used plenty of other stuff in the past. I think if you feel productive, that's the tool to use. If you feel curious, or whatever, I think it's worth exploring. Vim is peculiar because its interaction mode is so different that it's hard to feel fully at home with it without going all in for an extended period of time and dedicating yourself to learning some of the stuff that's not necessarily immediately apparent. If you do that, sometimes you find it really clicks with you. Sometimes you don't :)
  • dozzie 9y ago
    > - Recent vim in terminal (and vim in a GUI container like gvim or MacVim) supports mouse interactions. ...if by "recent" you mean a decade old version.
• cryptonector 9y ago
  vim has mouse support, though I don't know anything about it since... almost the whole point of vim is to not use a mouse.
• mrzool 9y ago
  > 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 Your problem with Vim is that you don't grok vi: https://stackoverflow.com/a/1220118/3078265 https://stackoverflow.com/a/1220118/3078265
• deleted 9y ago
  [deleted]
• gumby 9y ago
  > ...it still never beat GUI editors for me. The lack of a mouse cursor was always a pain point - for example simple copy/pastes take notably longer. Everybody's milage can vary; in my case it's 100% the opposite. Moving my hands off the keyboard is a demonstrable microinterruption. FWIW I've been using both text and mouse-based editors since I was 14, roughly 40 years. Some of the time was in deeply mouse-oriented environments (e.g. Xerox PARC in the era when Stu Card was proving that the mouse is indeed a better input approach for a plurality of people -- so I'm not claiming that the mouse is a bad idea in principle). But the keyboard is just so much more direct for me -- I don't have to look at it, and often don't move my eye from the insertion point on the screen even when referring to something elsewhere on the screen.
• coliveira 9y ago
  Vim has had support for mouse for at least 20 years.
• lanius 9y ago
  The individual user's keyboard and mouse proficiency determines their most efficient setup. I'm decent with Vim, but my mouse speed and accuracy is good enough to do many editing tasks with a mouse faster than I could accomplish in Vim.
• Tarean 9y ago
  I really want to say `text objects are faster than using the mouse anyway` but it is probably worth noting that vim has mouse support, even in most terminals. It should be default in neovim. In vim it is disabled by default and the help says > Normally you would enable the mouse in all four modes with: > :set mouse=a so I am not entirely sure why exactly this has to be done manually.
• blfr 9y ago
  Minimap. What I'm missing in all terminal editors is this neat overview of the file I'm editing. Everything else can be achieved with clever keyboard shortcuts, tmux, or hacking the .vimrc. It's just a matter of time and persistence. Similarly with mutt it's attachments. It just cannot handle them as well as a graphical/web mail client. (That and I mostly read my private email on the phone nowadays.)
• alwillis 9y ago
  It also sounds like you don't have relative line numbers enabled, which makes highlighting or jumping some number of lines quickly pretty trivial: https://jeffkreeftmeijer.com/vim-number/ https://jeffkreeftmeijer.com/vim-number/ A Vim truism: if what you're doing requires too many keystrokes or otherwise seems cumbersome, there's another way to do it that faster and requires fewer keystrokes. It's just a matter of whether you're interested in learning and not assuming you have it all figured out.
• alwillis 9y ago
  The mouse works fine with gVim; I use the Magic Mouse with MacVim (the Mac GUI version of gVim) for scrolling through large files sometimes. However, I never use the mouse in visual mode to highlight blocks of text; for that I'm much faster using Vim’s keyboard commands.
• deathanatos 9y ago
  > while in vim you have to go V 10d x 13down P or something along those lines, figuring out exactly what numbers to use there probably takes more than 1 second alone. Honestly, I usually just use 9j/9k[1] a bunch to get reasonably close / maybe overshoot a bit, and then adjust with j/k, using visual feedback to guide me. Much quicker than grabbing the mouse, IMO, or computing what line number to go to. (Admittedly, I should really learn the "go to end of block/paragraph/etc. keys.) You can also `set relativenumber`, which will change the line numbers on the side to be "relative" (that is, 2 lines down is labelled as "2"); this makes it obvious which number to hit. [1]: (move down/up 9 lines, 9 being an arbitrary "several")