6 ms·

Vim only got integrated gdb support last year? Emacs has had that since last century[0], I think. How do you people live like this? :-) [0]: https://github.com

Vim only got integrated gdb support last year? Emacs has had that since last century[0], I think. How do you people live like this? :-) [0]: https://github.com/emacs-mirror/emacs/blob/master/etc/NEWS.18#L127 https://github.com/emacs-mirror/emacs/blob/master/etc/NEWS.1...

intertextuality 7y ago
I guess it's not a vim article unless someone refers to emacs/another editor for no reason. Thanks for the unsubstantial comment. Regardless of editor X, Y, or Z, this article is about a feature Vim received. I for one find it useful since, well, I use vim.
- zeveb 7y ago
  > Thanks for the unsubstantial comment. Given that for decades a primary draw for vi was that it was simple, the fact that people keep adding features to it until it's approaching where Emacs was a few decades ago is noteworthy. Noting that Emacs has had a certain feature for decades, and that the feature has been receiving bug fixes and adding still more sub-features is substantial. Given that users of vim no longer seem to care about simplicity, one has to wonder: why stick with vim? Emacs has a far better extension language (elisp is to vimscript as a thermonuclear weapon is to a sharp stick), evil-mode can accurately replicate the vim editing experience, and Emacs has far more features and packages now than does vim. It's a bit like preferring a race car to a van because you want speed, but then deciding you want to haul packages for a living and bolting on a 2-ton flatbed to the back of your race car. You end up wasting fuel and still not carrying as many packages as you could with a good van — and not running as quickly, either.
  - mmcgaha 7y ago
    Having features and having features that serve a groups needs at the right time are different things. The first time I fired up emacs was in 1995 on a pentium 66 with 8 MB of RAM. It made my computer grind to a halt so editing text was not going to happen. When I tried vi, it ran like I expected a text editor to run. So here I am today, my fingers long trained up to use vi, and I find little need to learn emacs. Sure emacs has had useful features for years, but the barrier to entry was just too high, and now it is too late to win over folks like me.
    - mruts 7y ago
      But why is it to late? Evil mode works perfectly. I think you would find the transition quite easy.
      - s_c_r 7y ago
        It works fine as a vim emulation layer, but as a full replacement for vim it does no better than other vim emulations, like IdeaVim. For example, in vim I can hit : to open command line mode followed by ctrl + f to open a mini buffer for ex commands that can be manipulated like any other vim buffer. I use this feature all the time in vim and it isn't available in any of the vim emulation software I've tried. Now, I'm sure there are plenty of ways to accomplish the same goal in emacs, not disputing that. But the idea that evil mode can simply replace vim and all of its built in functionality? Just not true, at least not currently.
        ubercow13 7y ago
        Evil can function in the minibuffer too which is somewhat similar. Regardless, the idea that Evil is no better than IdeaVim is kind of ridiculous.
        socksy 7y ago
        Isn't that the same as q: (you know, such as there is q: , q/ and q?)? In which case, evil implements this as "evil-command-window-ex", which I'm sure you could bind to ctrl + f too (perhaps that should be filed as an issue with evil). But I'm equally sure that if you made a habit of using e.g. spacemacs, you probably would not need to use it all the time either. But I guess I don't know your workflow. Why do you even use that buffer? I curse every time I accidentally open it.
        s_c_r 7y ago
        I use it for the same reason I use bash history--to view, edit, and reuse ex commands. I'm not surprised that there is a way to customize evil to get to something similar, but my point was that it doesn't work out of the box the way vim does. I've no doubt that it could be implemented, and could file an issue as you suggest, but as someone who uses vim as my daily driver all I can say is every time I fire up evil I run into something like that which immediately turns me off. I guess I just don't have enough appetite for customizing my editor to take up emacs. Just noticed that :h doesn't open the vim help (of course, why should it, this is emacs), but there again, something I use several times a day. I could go on. A big reason I haven't tried harder is that there is no easy path to converting an existing .vimrc to elisp, and over the years I've spent enough time configuring vim to work just the way I want.
magpi3 7y ago
I know you are joking but for me vim was never meant to replace the command line. For me the terminal is the IDE. Vim is the editor, gdb is the debugger, grep is for text searching, etc. The desire to include more and more in vim mirrors what people have done with emacs but I personally have no use for making vim anything other than a very fast and efficient text editor.
- butteroverflow 7y ago
  I wouldn't dream of speaking for every vim user, but from casual observation it seems to me that `vim`ers tend to shed plugins as they get more experienced, instead of using more and more of them. So I believe your experience is quite typical.
  - commandlinefan 7y ago
    > tend to shed plugins There’s a practical side to that - the biggest benefit of vi(m) is that it’s _always_ there, no matter where you’re shelled in to. However, their vi doesn’t have your plugins. So if you get used to using plain-vanilla vi, you won’t be lost when you sit down at (or ssh into) somebody else’s computer.
    - heavenlyblue 7y ago
      >> down at (or ssh into) somebody else’s computer. Why would you develop software over SSH is seriously beyond me. Eg are you actually SSHing into your running docker containers to edit code? The only language that allows for it is PHP - because any other language is either compiled or needs modules to be reloaded. Are you viewing large datasets in csv files through vim? - This can’t possibly work as vim requires them loaded into memory. Are you editing config files on your servers using vim? - Do you not use automation to set everytting up on the servers?
      - KaiserPro 7y ago
        > SSHing into your running docker containers to edit code no, not primarily A few use cases: 1) I'm on a bastion host, and I need to knock up a script to run there 2) I'm working at home, and I don't want turn on the VPN, I SSH into my workstation and develop as if I was on the workstation 3) I need to change a conf/script/other because something is wrong, and the edit->commit->change config run-> test cycle is more than 2 seconds. 4) I'm in a container, debugging something and I want to edit a file (mostly python here so no need to compile) docker build-> run -> retry is painfully slow, and leaves loads of mess. 5) I'm working on a headless box somewhere or other. 6) I'm debugging on someone else's workstation I only really work with vim in a terminal, so doing it over SSH isn't actually all that noticeable. It does gets to be a problem when the latency is > 200ms

intertextuality 7y ago

I guess it's not a vim article unless someone refers to emacs/another editor for no reason. Thanks for the unsubstantial comment. Regardless of editor X, Y, or Z, this article is about a feature Vim received. I for one find it useful since, well, I use vim.

zeveb 7y ago
> Thanks for the unsubstantial comment. Given that for decades a primary draw for vi was that it was simple, the fact that people keep adding features to it until it's approaching where Emacs was a few decades ago is noteworthy. Noting that Emacs has had a certain feature for decades, and that the feature has been receiving bug fixes and adding still more sub-features is substantial. Given that users of vim no longer seem to care about simplicity, one has to wonder: why stick with vim? Emacs has a far better extension language (elisp is to vimscript as a thermonuclear weapon is to a sharp stick), evil-mode can accurately replicate the vim editing experience, and Emacs has far more features and packages now than does vim. It's a bit like preferring a race car to a van because you want speed, but then deciding you want to haul packages for a living and bolting on a 2-ton flatbed to the back of your race car. You end up wasting fuel and still not carrying as many packages as you could with a good van — and not running as quickly, either.
- mmcgaha 7y ago
  Having features and having features that serve a groups needs at the right time are different things. The first time I fired up emacs was in 1995 on a pentium 66 with 8 MB of RAM. It made my computer grind to a halt so editing text was not going to happen. When I tried vi, it ran like I expected a text editor to run. So here I am today, my fingers long trained up to use vi, and I find little need to learn emacs. Sure emacs has had useful features for years, but the barrier to entry was just too high, and now it is too late to win over folks like me.
  - mruts 7y ago
    But why is it to late? Evil mode works perfectly. I think you would find the transition quite easy.
    - s_c_r 7y ago
      It works fine as a vim emulation layer, but as a full replacement for vim it does no better than other vim emulations, like IdeaVim. For example, in vim I can hit : to open command line mode followed by ctrl + f to open a mini buffer for ex commands that can be manipulated like any other vim buffer. I use this feature all the time in vim and it isn't available in any of the vim emulation software I've tried. Now, I'm sure there are plenty of ways to accomplish the same goal in emacs, not disputing that. But the idea that evil mode can simply replace vim and all of its built in functionality? Just not true, at least not currently.
      - ubercow13 7y ago
        Evil can function in the minibuffer too which is somewhat similar. Regardless, the idea that Evil is no better than IdeaVim is kind of ridiculous.
      - socksy 7y ago
        Isn't that the same as q: (you know, such as there is q: , q/ and q?)? In which case, evil implements this as "evil-command-window-ex", which I'm sure you could bind to ctrl + f too (perhaps that should be filed as an issue with evil). But I'm equally sure that if you made a habit of using e.g. spacemacs, you probably would not need to use it all the time either. But I guess I don't know your workflow. Why do you even use that buffer? I curse every time I accidentally open it.
        s_c_r 7y ago
        I use it for the same reason I use bash history--to view, edit, and reuse ex commands. I'm not surprised that there is a way to customize evil to get to something similar, but my point was that it doesn't work out of the box the way vim does. I've no doubt that it could be implemented, and could file an issue as you suggest, but as someone who uses vim as my daily driver all I can say is every time I fire up evil I run into something like that which immediately turns me off. I guess I just don't have enough appetite for customizing my editor to take up emacs. Just noticed that :h doesn't open the vim help (of course, why should it, this is emacs), but there again, something I use several times a day. I could go on. A big reason I haven't tried harder is that there is no easy path to converting an existing .vimrc to elisp, and over the years I've spent enough time configuring vim to work just the way I want.

magpi3 7y ago

I know you are joking but for me vim was never meant to replace the command line. For me the terminal is the IDE. Vim is the editor, gdb is the debugger, grep is for text searching, etc. The desire to include more and more in vim mirrors what people have done with emacs but I personally have no use for making vim anything other than a very fast and efficient text editor.

butteroverflow 7y ago
I wouldn't dream of speaking for every vim user, but from casual observation it seems to me that `vim`ers tend to shed plugins as they get more experienced, instead of using more and more of them. So I believe your experience is quite typical.
- commandlinefan 7y ago
  > tend to shed plugins There’s a practical side to that - the biggest benefit of vi(m) is that it’s _always_ there, no matter where you’re shelled in to. However, their vi doesn’t have your plugins. So if you get used to using plain-vanilla vi, you won’t be lost when you sit down at (or ssh into) somebody else’s computer.
  - heavenlyblue 7y ago
    >> down at (or ssh into) somebody else’s computer. Why would you develop software over SSH is seriously beyond me. Eg are you actually SSHing into your running docker containers to edit code? The only language that allows for it is PHP - because any other language is either compiled or needs modules to be reloaded. Are you viewing large datasets in csv files through vim? - This can’t possibly work as vim requires them loaded into memory. Are you editing config files on your servers using vim? - Do you not use automation to set everytting up on the servers?
    - KaiserPro 7y ago
      > SSHing into your running docker containers to edit code no, not primarily A few use cases: 1) I'm on a bastion host, and I need to knock up a script to run there 2) I'm working at home, and I don't want turn on the VPN, I SSH into my workstation and develop as if I was on the workstation 3) I need to change a conf/script/other because something is wrong, and the edit->commit->change config run-> test cycle is more than 2 seconds. 4) I'm in a container, debugging something and I want to edit a file (mostly python here so no need to compile) docker build-> run -> retry is painfully slow, and leaves loads of mess. 5) I'm working on a headless box somewhere or other. 6) I'm debugging on someone else's workstation I only really work with vim in a terminal, so doing it over SSH isn't actually all that noticeable. It does gets to be a problem when the latency is > 200ms