1. 41
  1.  

  2. 19

    Great points about editing, but the use case shouldn’t be glossed over: “You might need to edit files via SSH.”

    It’s wonderful to have the powerful edit commands, but this use case shouldn’t be understated. Every time I’ve needed to edit or examine a file on a remote linux server, VIM’s always been there.

    I’ve spent thousands of hours writing code in VIM, but it’s not a true IDE. However, it doesn’t require X running, uses few resources itself (plugins are another matter), has regex search/replace built in, and you can run it inside screen or tmux in case your connection drops or to resume editing sessions. Knowing VIM in 2020 is like showing up to a job site and your toolbox is already there.

    1. 16

      The other side of editing over SSH is Emacs and TRAMP mode: Use your local Emacs to transparently edit files over SSH. The remote system doesn’t need to have any editors at all installed, necessarily.

      https://www.emacswiki.org/emacs/TrampMode

      1. 7

        TRAMP also allows you to use your local emacs setup and doesn’t incur network latency when editing, neither of which apply to vim through ssh.

        1. 5

          And it allows you to have different buffers in the same Emacs instance connected to different remotes. This means, among other things, that you can use dual-pane (orthodox) file manager Sunrise in Emacs with each pane pointing to a different remote, and copying and editing files between them as if they were both local.

          1. 1

            Can it keep a single buffer for multiple remotes? To push all changes in the buffer to all of the remotes.

            1. 2

              That’s not something I’ve explored. My best guess would be “no, not out of the box, but probably combined with some other mode that keeps multiple buffers synchronised.”

              1. 1

                Isn’t some sort of source control a better tool for this task?

        2. 7

          People always bring up this point, but - and I say this being proficient with both vim and emacs - for those who aren’t doing sysadmin/devops/sre work, is this a good reason to spend time learning more than insert mode, arrow keys, esc, and :wq? And for those who are in the business of regularly editing files remotely: don’t they already know? For those of us who don’t spend a lot of time connecting to remote machines:

          • How often should we be editing files on remote hosts? Don’t we have “better” tools for configuring remote machines, e.g. ansible?
          • I’m only ever connecting to remotes that I’m in control of. If I need a program to be available, it’s easy to make it happen.
          • The few times I do have to edit a file on a remote host, I typically only have to make small edits to unbreak something. What degree of competency with an editor is really required to change a few lines?
          • If I weren’t comfortable with vim, but needed to do some heavy lifting on a remote, many editors have features for making this happen.
          1. 2

            You might edit files on remote servers rarely but I do it all day every day. For the reasons mentioned in sibling posts, tramp on emacs makes it both a transparent and rich editing experience.

            1. 1

              is this a good reason to spend time learning more than insert mode, arrow keys, esc, and :wq?

              On my terminal setup, arrow keys aren’t interpreted correctly so I have to use hjkl ;)

              Also :q! is great for when you’ve messed everything up and need to start over…

            2. 2

              If I wrote a post on vim I would deliberately skip this point because I get so little value out of it that it feels almost derogatory to how great modal editing is to make a big deal about just being there.

              I seem to be alone in how small a percentage of my time is spent doing serious editing on remote servers though.

              1. 2

                Not necessarily, considering that part of Vi’s history is that it was developed in high-latency environments, where you wanted to compress as much “editing information” into as few keystrokes. This fact still turns out to be helpful over slow connections today. Holding backspace for a few seconds and then undo because (due to the lag) it went a few characters too far, is more annoying that pressing dd to remove a line.

                1. 3

                  Holding backspace for a few seconds and then undo because (due to the lag) it went a few characters too far, is more annoying that pressing dd to remove a line.

                  I can’t tell if this example is representative of how Vi users use non-Vi text editors (holding backspace for a few seconds to delete a line) or if this is representative of how Vi users think users of other text editors delete a line.

            3. 22

              If you’re the kind of person who’s willing to put up with a learning curve and a smaller ecosystem of plugins to gain access to a powerful editing model, also consider Kakoune. It’s like Vim, but moreso.

              1. 8

                I simply can’t go back to Vim after using Kakoune. Feels like a step back to me.

                1. 8

                  I am in the same boat. I think by and large Kakoune is a step up from Vim. That said, it is not emulated in very many other places (it is in vs-code now via dance) – so you do lose the ability to pop into IDE of your choice and have a good experience.

                  1. 2

                    Dance is cool, but there are a lot of little things that does not work the same way and it’s annoying.

                    When i’m at the beginning of a line and press x, it doesn’t select the line. It selects the line below. If i go forward one character before pressing x, it works.

                    It’s good enough…

                    1. 1

                      That smells like a bug more than a difference.

                  2. 1

                    I wish emacs had a kakoune mode like the evil mode. It would help me pick up emacs finally. Each time I have tried evil, I got stuck in small differences with vim.

                    1. 2

                      Unfortunately every emulation of another editor is not the same thing.

                      I use kakoune to write small programs and scripts, but i have vscode as well. Vscode has a plugin called “dance”, it is a kakoune simulation plugin. It works, but not very much…

                      The problem is the little things… there is always something that doesn’t really work the same and becomes annoying.

                  3. 6

                    How would you say the transition to Kakoune from someone who’s been using vim for awhile is like? I took it for a spin and am very confused, but I can already see things that I like.

                    1. 6

                      I switched from vim to kakoune about 6 months ago. I think the majority of the users, including the author himself, came from vim. My strategy was to switch entirely for a week then decide if it was worth committing fully or not. I never went back to vim. Once you get over the initial hurdle of unlearning your vim muscle memory, kakoune is very intuitive to learn, more so than vim in my opinion.

                      1. 4

                        Seconding ifreund’s experience, I came to Kakoune after maybe 20 years using Vim and it took me maybe a month for Kakoune to feel comfortable. The biggest hurdles for me were a few commonly-used key-bindings that changed (x in Kakoune is “select the current line”, not “delete the character under the cursor), and that Kakoune is a little bit like that “Snake” game on old Nokia phones: as you’re moving around, you need to be conscious of where the “tail” of your selection is as well as the “head”.

                        The thing I love most about Kakoune is global search-and-replace. In Vim, I’d often wind up in a cycle of “write a replacement regex, try it, check the document, find a mistake, undo, try again”, which was particularly frustrating when the thing I wanted to select was easy to describe in Vim’s normal mode (like % to select a matched pair of brackets) but difficult to describe in regex. Meanwhile, in Kakoune, I can match a regex across the entire document, producing multiple selections, cycle through them all to check I’ve selected the right things, manually adjust them with normal-mode commands or even drop false-positives, and then do the replacement. It’s more work than the best-case Vim equivalent, but far smoother and more pleasant than the worst-case Vim equivalent.

                        1. 2

                          I know you don’t use Vim anymore but for anyone else who has the problem described in the second paragraph: traces.vim offers a live preview that makes searching and replacing easier, if not quite as easy as it seems to be in Kakoune. As you’re typing a :s command, the plugin will highlight the parts of the file or line that would be matched, and it will also show you what they would be replaced with. It’s pretty magical.

                      2. 3

                        I really want to, but the hidden benefit of Vim keybindings is they translate to other programs too (I assume Vim people are just very militant and force devs to support them ;) ) so I can use IntelliJ or Emacs or even a web-based IDE and have access to those bindings. If I changed muscle memory to Kakoune, I’m going to be in trouble for hopping between programs.

                        1. 3

                          powerful editing model

                          Can someone pitch to me, the established emacs user, what the benefits of Kakoune are? I have multiple cursors package enabled, plus helm and swoop (intra file fuzzy matching), but I presume Kakoune presents more benefits.

                          1. 7

                            EDIT: This explains it better https://kakoune.org/why-kakoune/why-kakoune.html


                            Disclaimer: I’ve used Emacs for fewer than 10 hours in my life. I remember very little.

                            The last time I looked into it, the big difference that Kakoune brings to the table is that nouns come before verbs. This feels minor but in practice it makes discoverability so much easier because you’re deciding which text to act upon before doing an action.

                            For example, in Vim if you want to delete three words you type d3w, and if you realize that you meant to delete 2 words then you have to undo and try again. Kakoune lets you make your selection first, highlighting as you go, and makes it easy to change your selection before taking an action. It’s also constantly auto-completing with all of the possible commands you might want to make, which is much simpler than reading through a manual.

                            1. 2

                              Not having used the Emacs multiple cursors package (or Emacs at all, really) it’s hard for me to say what the advantages of Kakoune’s editing model might be. If I had to guess, though, I suspect the biggest difference would be that since the Emacs core is only built for single selections, most Emacs functionality (including third-party extensions, etc.) only works with single selections, except for the things that the multiple cursors package specifically modifies. Meanwhile, all of Kakoune’s standard features and third-party extensions deal with multiple selections, so you don’t need a mental model of how single-selection features interact with multiple-selection data.

                              I don’t know how complete Emacs’ multiple cursors package is, but I expect it has all the same kinds of cursor interactions as Kakoune, like selecting substrings of the selection that match a regex, splitting the selection on a regex, dropping selections that do/do not match a regex, dropping selections interactively, rotating content through selections, etc. If not, that might be another reason to try Kakoune!

                          2. 12

                            Here’s a potentially unpopular opinion: for the typical application developer, vim is not worth learning more than a passing knowledge of, because editing raw text is infrequently a bottleneck in programming. Having spent years as a vim user, and then years as an emacs user, and currently using neither with any frequency, I’ve found that these things require the most amount of creative energy:

                            • Understanding the task at hand so that I don’t accidentally solve the wrong problem
                            • Modeling a solution that seems reasonable by thinking and taking notes
                            • Reading documentation in a web browser
                            • Navigating through a codebase that could be anywhere from 50k-150k sloc in order to understand the interfaces my changes will be involved with
                            • Sometimes renaming definitions or moving code between modules

                            In terms of the act of changing lines of code, the #1 time saver (and what keeps me from getting distracted) is navigating by concepts of my programming language, not via the unix filesystem, text search, or even fuzzy file search. The other big one is having the editor itself seamlessly report any statically known issues to me as I’m working. The last one is, when I’m really just manipulating text, having at least 80% of my ideal set of text editing commands available so as to cut down on both keystrokes and mouse fiddling.

                            Vim can for sure do these higher-level things, but last I tried, it takes significant configuration effort to keep up, and the results aren’t reliable and require a lot of maintenance. Vim emulation layers, even when done really well, don’t significantly improve my development experience, even less so when hosted in editors that provide all the other benefits. It’s cool that vim has a whole DSL for operating on text objects, but in practice the time saved is not worth the salt.

                            By all means, if vim seems fun or scratches a curious itch or if you connect to it emotionally then learn it, and enjoy it! It’s definitely creatively fulfilling for a lot of people. I sort of woke up one day though and realized that while I may have saved a few minutes throughout the day on text manipulation, I lost much more time fussing with all the different methods for navigating any codebase over ~50 files or so.

                            1. 10

                              vim is like a curse, in that after you get comfortable with it you won’t be able to use a normal text editor anymore, lest your buffers fill with jjjjjjkkk. Fortunately there’s vim plugins for most IDEs and text editors you’ll need to use, but they all have their quirks and bugs and unsupported features, so you’ll end up using only the subset of vim that is supported by all the IDEs you’re using at the moment.

                              1. 9

                                Because it’s the one text editor that doesn’t murder me with RSI.

                                1. 4

                                  Same. I tried using Emacs for a while and the constant need to hold down modifier keys made it physically painful.

                                  1. 3

                                    As an Emacs user I have to agree. It’s just that the benefits I get from using Emacs outweigh the pain…

                                    1. 3

                                      vim user rolls eyes… Causing physical pain in a completely avoidable way imho means that emacs is not meeting very basic prerequisites, however great the rest may be :)

                                      1. 2

                                        Ever heard of Evil mode? It is possible to get the best of both worlds, and I have trouble understanding why someone wouldn’t want that.

                                        1. 1

                                          I don’t know if it’s avoidable, beyond taking breaks from time to time. I’ve tried emulation packages (viper, evil), and different editing ideas (lispy, objed) but they always confuse me.

                                    2. 1

                                      I had this problem with Emacs until I learned how to press Ctrl key with the palm instead of the pinky finger.

                                      1. 5

                                        Wait, doesn’t everyone remap caps lock to control when they set up a new computer?!

                                    3. 12

                                      I recommend Emacs instead: it is a full-blown text-oriented operating system built atop Lisp, with a ton of useful packages building on decades of work.

                                      It even comes with vim compatibility, if you want it!

                                      1. 3

                                        “it is a full-blown text-oriented operating system built atop [x]” actually sounds like a scary antifeature?

                                        1. 3

                                          Yeah, it could as well have been. By a miracle stroke of luck, it actually works out really well for Emacs. Think less JavaScript, more JVM.

                                          1. 2

                                            I believe that’s a reference to the joke

                                            Emacs is a great operating system missing only a decent text editor

                                          2. 1

                                            I’ve been using emacs (spacemacs) for a few months, and there are some things I like about it. However the “vim mode” is clearly not desgned by vim users. By default it jumps all over your file highlighting things as you search! I had to write nontrivial lisp to fix that, there is no config option.

                                            I also still haven’t found a way to make my tab key behave sensibly. I figured out how to neuter the awful indenting in prog mode, and set tabstop+shiftwidth and not insert spaces when I push tab… but every new mode I use may require redoing all this work. More than once I’ve opened a new type of file, made a trivial edit, sent it off only to find emacs had inserted whitespace errors facepalm

                                            1. 2

                                              I think before slamming Evil mode you should try it on its own, without all of the other Spacemacs stuff. Spacemacs notoriously adds a lot of things that they (and, I guess, many of their users) think are nice, but it’s far from plain Evil mode. Plain Evil mode is indeed desigend by Vim users, and any incompatibility with Vim is a bug, not a feature.

                                              1. 1

                                                I will try it, but from my reading if the code both of the problems I list are not spacemacs extras.

                                                1. 1

                                                  Then i urge you to filé a bug report. The Evil maintainers are serious about compatibility.

                                                  1. 1

                                                    I filed one of them https://github.com/emacs-evil/evil/issues/1304 and got the help needed for a workaround.

                                                    Everywhere I look for “how to make tab key behave” is just people asking why one would want that, but I guess since it’s a regression from vim I coukd try to file it for evil…

                                          3. 7

                                            When I learned about . I became more enlightened.

                                            1. 7

                                              I think you can read a thousand blog posts praising the merits of Vim editing, but you won’t really get how powerful it is until you see an advanced user working with it. It’s like a superpower.

                                              1. 6

                                                nano for all my editing needs in a terminal.

                                                1. 4
                                                2. 6

                                                  Or, learn VIM commands while learning elisp. Emacs with VIM bindings is best of two worlds.

                                                  1. 6

                                                    With the caveat that:

                                                    1. Sometimes Emacs will drop into a state where vim emulation doesn’t work and you’ll have no idea what’s happening. Even after learning the canonical Emacs, this is really schizophrenic.
                                                    2. evil-mode, like all vim emulators, is flawed. In particular:
                                                      1. Block selection (^v) works differently. Namely, if I first activate block selection and then hit I to insert text in all the rows at the given column, Vim will ignore empty lines (or lines where this column is past the end of the line). evil-mode will not, it will do the same as rectangular selection in Emacs. IME the Emacs thing is never useful (more like annoying, since I have to clean up after evil-mode each time), whereas the Vim way is perfect.
                                                      2. evil-mode doesn’t implement gn from Vim.
                                                      3. You have to keep patching things around in your config to keep things working. Like the tab key behaviour in code snippets in org-mode, which evil-mode breaks (for python code snippets); or “persisted search highlight” which is also very weird after you get it working.
                                                    3. Emacs is slow. I don’t mean just the startup, which I managed to bring down to 0.2 seconds (the time it takes to start even with zero config, so it won’t get any better; if you use org-babel to keep your config in an org-mode file, you won’t get under a second and even that’s an exercise). Fuzzy file search in projectile+ivy (that’s faster then with helm) feels sluggish after using fzf in vim. And fzf in Emacs looks and feels really alien. Also, performing undo multiple times in a row really shows latency (as in I can see it with my eyes) — that’s a source of irritation. All those things are, from human perspective, immediate in Vim.

                                                    I’ll take Vim over all that. With a really short config everything’s fast and doesn’t break on every turn. (It helps when your way of working (in this case the vim way) is the default way.)

                                                    1. 4

                                                      The meme that emacs is slow to start up really needs to be put to bed.

                                                      Your browser is slow to start up but you don’t start it up every time you want to view a web page. You start it once and open pages as you go. Same with emacs. Start it up once when you login. Then open files using emacsclient. Then it’s no slower than vim.

                                                      1. 6

                                                        “Don’t perform a startup” is not a good counterargument to “startup is slow”. It’s like answering “don’t shutdown your computer when using Windows” to “Windows is slow to boot”.

                                                        Yes, my browser is slow to start up and I think of my browser as a pile of garbage. I don’t enjoy using it. I’m forced to use it. Besides, that was only a minor point. Yes, once I start Emacs, I can open files from there. But I just wrote how: 1. finding files is slow; 2. basic operations like “undo” are ridiculously slow. I don’t know, maybe Emacs mines bitcoins when I hit undo, as punishment for my mistakes. So anyway, leaving Emacs open doesn’t make it any more responsive further down the road.

                                                        1. 1

                                                          I tend to start a session in a Tmux window. Sometimes when I exit to reboot I find buffers that are months old…

                                                        2. 2

                                                          Re: #3 - gccemacs may be integrated with master and deliver real perf gains: https://akrl.sdf.org/gccemacs.html#org4c175c8

                                                      2. 1

                                                        I love vim as an editor. I’d consider myself an advanced beginner, stuck in the lurch of needing to put a lot more time in in order to move past that. And yet, for many projects, I just don’t want to use vim. For C++, CLion almost makes me forget how good Visual Studio is. For Rust, VSCode + rust-analyzer is amazing. For Python, VSCode’s basic linter finds about 70% of my typos (the bugs I take full responsibility for). (I know you can add language support via language servers.)

                                                        Fundamentally, I see programming more about building models via ASTs, rather than building something via text. It sounds kind of pretentious that way; I’m not sure how else to describe it. It just seems like there’s a certain genre of programming that fits better with vim, and it is places where type information is not as important. The other thing is I don’t spend much time actually writing code; most of it is in massaging/refactoring/thinking of ways to get things to happen. The writing part seems secondary.

                                                        Other thing is I currently dislike tools that seem like they require a ton of config. I just don’t care about doing that generally. neovim is a big boon to me; I put it on and aliased vim to it and really like the defaults. But I’m not sure if I feel the need to actually configure neovim like I did for many years.

                                                        I joke with people that my 2020 vim config is: $ rm -rf $dotfiles_root/vim; brew cask install vscode.

                                                        1. 2

                                                          Look into coc.nvim; you can use language servers like rust-analyzer in vim itself.

                                                          1. 1

                                                            I use the Rust plugin with CLion, and prefer the experience to VSCode + Rust Analyzer. I think the IntelliJ Rust plugin also fits well with your view of “editing ASTs, not text”, because the plugin is a Rust parser.

                                                            CLion + IntelliJ also beat VSCode in terms of how easy they are to configure.