My thoughts after coding for 15 years now... I still can’t be bothered to learn emacs or vim. I’ve tried and it just never sticks. I remember fewer commands in vim than I knew 10 years ago.
I really like smart IDE’s like IntelliJ and pycharm. I’m doing a typescript project in VSCode and the refactoring and code understanding is just... not enough. I agree with James Gosling’s opinion of heavy IDE’s. They help me. I’m not out to prove any my manliness
Also, I feel like I do more reading code and debugging than writing nowadays, and I am not bothered by my speed at writing code.
> I still can’t be bothered to learn emacs or vim. I’ve tried and it just never sticks. I remember fewer commands in vim than I knew 10 years ago.
It's kind of the opposite for me. One day I read an interesting comment about vim and took the vimtutor out of curiosity and it immediately clicked. I always hated learning keyboard shortcuts in other applications and I always forgot them shortly after, but with vim it feels like having learned a tiny foreign language. There's a small grammar and a small vocabulary, which means you don't have to remember each keyboard shortcut, just like you I don't have to remember every sentence of the English language. And the best thing is, every single tiny addition to your vocabulary allows to form a plethora of new sentences, so it always felt amazing learning a new motion or text object in vim.
> Also, I feel like I do more reading code and debugging than writing nowadays, and I am not bothered by my speed at writing code.
I am neither. But I feel editing text with vim needs less thinking on my part, i.e. I can translate my intend easily to vims language without getting interrupted too much.
It’s always seemed silly to me not to use tools that make your job easier. JetBrains products are the most powerful software I have to get my work done.
Those things are often huge, slow, and take a long time to learn—not all sunshine and roses. When the control panel has search you know you're in one. All a tradeoff of course.
But is the alternative really all that better? I love vim, but without a bunch of plugins it's fairly rough to use. VSCode seems the same. So to me it looks like you're trading one complexity (learning about your tool) for another (having to search left and right for the right plugins, see how they work, etc).
Software dev is not my day job, although I do it often enough to have a PyCharm license. I've purchased that because working with Django just works. It knows how to refactor, it understands the meanings of strings in configurations, it can run a local editor with local analysis / completion / etc but do the actual code running / debugging on a remote machine. All this out of the box and very easily set up. Can VSCode do this? I don't know, maybe. But I know that it doesn't have python support out of the box. So instead of having to search through the settings of PyCharm (which, to me, have fairly sane defaults) I have to search through the plugins of VSCode.
I'm also trying Rust a bit. There's a JetBrains plugin for it, it just works. It was fairly bare bones, now it's getting smarter and smarter with respect to refactoring, etc. Last I looked in VS Code, there were multiple rust plugins. Which should I pick? I get that choice is good, don't get me wrong. My point is that using a "simple" editor isn't all that simple either. It's always a trade off of sorts.
Now, if your point is that all you need is vim with a nice color scheme, I understand that, too. And in that case, you've got a point. But I guess that, as GP said, if there are tools available that are there to help you, some people like using them.
Jetbrains IDE's definitely aren't slow. You need to change the default memory heap sizes.
Same codebase loaded up in Webstorm vs VS Code and I can't see any difference.
Webstorm took about 10-20 seconds to index it but their implementation of the AST is unbelievable. So much more powerful than VS Code. I get code completion in way more places than VS Code and even when they both provide options Webstorm takes the local context into account and much more accurate than VS Code. Refactoring is breeze.
There is no comparison. I happily pay the initial load up time in the morning for smoother ride for the rest of the day.
Huge but not really slow. They automate a lot of common tasks, super fast searches/navigation, refactoring etc. Code analysis is just there. Often my fellow non-IDE users struggle to find the piece of code when we're chatting whereas for me navigating or finding things anywhere in a really large code base is pretty much instant. I stopped pointing it out unless it's a good friend I just want to rib a little.
Most non-IDE users I meet IRL don't take the time to beef up their tool and actually learn how to properly use it. There are also those who flat out refuse to install any plugins, for example, plugins that could make searching large codebases very fast. I don't understand these people, but to each their own! <3
Of course, the whole reason many people chose an editor over an IDE is because they don't want to learn an IDE so, not much you can do there. I've worked with plenty of people who use an IDE and barely using any of its features.
I've never used ripgrep... Does it do offline indexing? because that's what my IDE does and why search is instant. Tools that actually have to go and search everything will never be as fast. Obviously that sort of functionality can exist outside an IDE... And functionality can be added via plugins to any editor...
Not yet. But offline indexing isn't going to matter much until the amount of code you need to search is many GBs and/or doesn't fit in your page cache.
That was essentially what I was getting at :) ...the difference being those who have these wired up into their text editors vs those who have to context switch between editor and terminal.
I haven't found Jetbrains IDEs to be slow in my personal experience. Assuming a beefy CPU and enough memory, I've found Intellij to be really zippy - instantly switching between files in large projects, no lag during text editing etc.
I can understand why you have this idea though - most other IDEs I have used have been noticeably sluggish compared to more lightweight editors even on high end hardware.
It's hard to imagine the slowness isn't outweighed by the speed gains from Intellisense and automatic refactoring tools.
with Webstorm / IntelliJ you can write first using placeholder variable names in a single file. One click to rename the variable and all references throughout the app. Drag the file to a different folder and imports are fixed everywhere. Want to move a single function to a different file? One click or keyboard shortcut and you're there.
I'm 10 years in and I'm the same. My editor is never, ever my bottleneck. Especially not to the degree that I'm going to sink dozens of hours into learning one. It has never gotten in my way and I just don't care. I have given Vim a couple of hours, realised I was learning solutions to problems I never had, and I moved on. Life's too short for that noise.
The important lesson with vim is that you should be able to edit faster than you can think. It doesn't matter whether you use vim keybindings or emacs keybindings, or whatever, just that you have replacements for the functionality so that your brain can be free to think about the problem at hand rather than the nifty-gritty of editing text.
> I’m doing a typescript project in VSCode and the refactoring and code understanding is just... not enough.
What's your exact complaint?
Find and Replace or repeatedly hitting Ctrl+D covers 90% of my refactoring needs and I work on mostly TypeScript / JavaScript code. The other 10% is covered by "Extract to function" which I rarely use because it's easy enough to cut and paste.
Renaming a file is a very easy 2 step process. 1) Rename the file. 2) Find and replace `/filename"` with `/new-filename"`.
I almost exclusively use named exports, so renaming a symbol is a simple find and replace.
Coding for many more than 15 years, use vim. Would never tell others to use it, its individual. For me, the speed, power, and omnipresence of it, makes it worth spending the time to master it. My workflow makes it important to be editing a file within a second of realizing I want to. Launching an IDE is way too much friction.
I use vim bindings whenever I can, though I never use vim. I don't know most of the commands beyond navigation and basic editing, but using h, j, k, l and deleting, yanking, pasting entire lines with dd, yy, C, p, etc. are far less tedious the using the mouse and arrow keys.
I have been mostly writing and refactoring new code in last 3 years. Writing is easy. Can't imagine doing refactoring in vim with 1/10 efficiency of ReSharper.
It's funny how people can differ. I despise IDE so much .. sometimes with good arguments (non ergonomic, non helpful, bloated, non customizable, configuration hidden somewhere..).
I found vim edition natural, emacs programmability very natural. But it's true there was a holier than thou at first.
It's interesting that none of all this is really the reason why I use what I use ... I use vim simply because it is ubiquitously installed on every linux and Mac system no matter what or where, including keybindings in every other editor or IDE I would ever encounter, including the bash command line (after set -o vi) and FireFox (with SurfingKeys).
The fact that it happens to be powerful enough to do everything I want is of course necessary, but there are dozens of editors that satisfy that requirement. Simply not having to switch out of Vim navigation or move my hands off the keyboard for the whole day across the dozens of different tools that I use is what makes it a winner.
> I use vim simply because it is ubiquitously installed on every linux and Mac system no matter what or where
This was also my initial reason for learning Vim so that I could comfortably write code on any machine I encountered, but the editing experience was actually really fast and enjoyable so I stuck with it ever since.
I used to use vi/vim more, because it is available just about everywhere and it's great for quickly editing a config file on a remote system.
But once I started using tramp, I now use emacs for all systems.
Tramp is a built-in way of editing files on remote systems using ssh as the transport. I can edit remote config files on dumb iot devices that don't run much more than busybox - with highlighting and undo and all the full-featured stuff.
open /ssh:foo:.profile to edit your profile on remote system foo.
You can also mix files - local and remote - all in different buffers. copy/paste between them, etc.
One thing he mentioned I haven't tried is LSP. anyone have any tips?
> But once I started using tramp, I now use emacs for all systems.
> Tramp is a built-in way of editing files on remote systems using ssh as the transport. I can edit remote config files on dumb iot devices that don't run much more than busybox - with highlighting and undo and all the full-featured stuff.
> open /ssh:foo:.profile to edit your profile on remote system foo.
Vim does it through scp:
vim scp://user@host//path/to/file
I don't usually use it (since vim is pretty much guaranteed to be installed remotely anyway), so I don't know what pitfalls/weirdness may exist, I just know it has the functionality.
I’m a big fan of the JetBrains ecosystem which I think has won the IDE wars (given its ubiquity). Once you get comfortable working in one of their tools and configure it to your needs it’s easy to carry that over to the next tool.
What I was never sold on was their DB offering Datagrip which never felt intuitive for my work. There I was a big fan of SequelPro for MySQL but when it comes to other RDBMS the jury is still out (have tried Navicat, TablePlus, and a myriad others)
> Even though it could be seen as a positive point, I think that all the great plugins emacs has make it very bloated, and that’s a problem to me. For instance, Org-mode, which is a wonderful piece of software, should have benefited much more people if it was a standalone application. To me, it feels like starting using emacs will lead to using your computer to run emacs, and all your applications inside emacs. It even has an IRC plugin and an email reader plugin!
That's the point, yes.
Emacs' philosophy isn't so much text editing as it is using text as a convenient representation of something else and then having a powerful set of text-editing primitives you can use to manipulate whatever it is you're using text to represent. Living inside Emacs means always getting to use those customized, "slick" (in the author's words) text editing commands to do everything.
Emacs has gotten to where Web browsers are going, except Emacs isn't evil unless you actively make it so. ;)
During the period of about 10 years that I was using Emacs as my main editor, I invested countless hours in mastering Elisp, configuring this and that, writing custom functions, fixing abandoned minor modes that I still found useful... It was literally all over the place.
At some point, the list of things that were broken/didn't work well for me got quite long, and I became dissatisfied enough to stop what I was doing and start going through various elisp packages, trying to understand what was really happening.
Let me say first, that I really admire and respect the potential of Lisp. When the code is well written, it is elegant, reasonably comprehensible, and malleable. However, when the code gets sloppy or unnecessary levels of abstraction are added to 'just make things work', it quickly becomes inscrutable. I kept running into package after package of this kind of poorly written, inscrutable Elisp. One package was using EIEIO (object-oriented Elisp) and there were excess levels of indirection all over the place, across thousands of lines of code.
Org-tables are pretty neat, but ultimately a fancy gimmick. I had a 7 column table, and after 200 rows, the reformatting became ridiculously slow. After looking through the tens of thousands of lines of org-mode Elisp code, my main question was, "Is all this code really necessary?" I know that org-mode does a lot, but Elisp is a dynamically typed scripting-level language. With macros. What went wrong?
Did you try to see what made the table unusable? If you feel want, you can report this to emacs-orgmode@gnu.org and maybe we can do something about it. Thanks!
I've sunk a pretty substantial amount of time into learning vim (neovim) and imo it's paid big dividends in taking the monotony out of text editing tasks. But, I don't limit myself to one tool. If I need a graphical debugger or the language doesn't have a fast lightweight language server, I use an IDE.
I switch between neovim and an IDE pretty frequently. I use yakuake to open up a terminal when I need it. best of both worlds! Plugins like comrade[1] make this pairing delightful. If your definition of a VIM mode only includes text objects and navigation, than an IDE with VIM bindings is plenty to replace it, but it doesn't cut it for me. My workflow has become reliant on VIM macros, global commands, buffers, and filters. I also haven't found a compelling reason to replace Fugitive[2] for another Git GUI.
None of the stuff I do in neovim is necessary, but it's fast, flexible, a bit obtuse, and pretty dang fun.
It's tough to fill the editing niche VIM fits because of the peculiarities that make it VIM. Doesn't mean that it's the de facto editor for every situation.
I spent some time learning emacs, and I use it every time I'm in the terminal and need quick access to a file, or SSH into a machine, but there's no way I'll ever spend the time to make it my main editor. The learning curve is not steep, it's fixed to a "hard" mode: every new plugin you want to try, you'll have to figure out how to use and there'll be some time adaptation to learn new shortcuts.
While I don't see them dying, since editors in a terminal is still a thing, but I'm wondering if we're going to see alternatives popping up at some point, or perhaps VSCode will have a "ssh into this machine and open the file in the editor" flow at some point.
Realistically editors like VSCode and Sublime text are the future: easily extendable AND it's fast to try new plugins. If you don't remember a shortcut just cmd + P, fuzzy type what you want to do, remember the shortcut displayed next to the name for next time.
Emacs has something like that as well with the right plugins. Ctrl+h f then fuzzy type what you want to do. Or, like usual, alt+x then start typing to just execute that command instead of reading about it. You just need the plugin Helm, or Ivy. I use Doom Emacs, and this functionality is built in. I use it all the time. Same story with config variables, except it's ctrl+h v instead of f.
I love my emacs commands and I have a .emacs file with various snippets and packages like any good user, but I've been finding myself using it less and less.
First it started with front end development. I couldn't get emacs to play nice with syntax highlighting modern front end. I could get JSX highlighted OR I could get TypeScript highlighted. Not both. I started using WebStorm and discovered that the emacs keybindings were pretty good! Not perfect but the best I've found outside of emacs. And the refactoring! So nice, so convenient.
I still used emacs for various languages. Ruby, Python, then some Rust. I wrote a solid amount of Rust in emacs. But then my Rust projects started growing, I started wanting automatic refactors and good type info. A couple times setting up language servers on emacs had chastened me. So I switched to IntelliJ Rust. And damn, it's really nice. Same decent emacs keybindings, with really good language tooling. I can see the inferred type of a variable while I'm typing it out. I can refactor without having to run cargo all the time.
At this point I use emacs for writing blog posts, Python/Ruby, and config files. That's it. Oh and debugging wasm binaries. Hexl-mode is still unrivaled. It's a little sad though. I learned to program as I learned emacs. I like the idea of having a powerful, text crunching editor. But it's so damn inconvenient. Everything feels a little tacked on. Language servers are super brittle and hard to get right. Multiple cursors mostly work but aren't the first class citizens of IntelliJ.
If I had to provide a thesis on why emacs is failing me, it's because emacs was designed to manipulate text. It's incredibly good at that. But code these days isn't text. It's hypertext. It's a code graph that is automatically formatted, refactored and linked. Emacs can certainly treat code that way, but it's a lot of work and a lot of suffering that IDEs provide out of the box.
I have a tendency to switch between VSCode and Neovim on a semiannual basis--mostly to come back to the speed and native vi in Neovim, only to switch back after going through plugin hell for weeks.
Neovim could be a great editor if they spent more time adding core plugins to the main program. I see it's starting to happen a little with the built in LSP and package manager, but it should do more. The docs are a mess for configuring some of these bleeding edge features (like the floating windows), and it definitely impacts my workflow without them.
On the flip side, VSCode has too many "non sensible" defaults for my liking, especially between versions. Nothing grinds my gears more than making a big edit, only to look at the diff and realize some plugin decided to autoformat everything. VSCode also has a tendency to hang, especially with vim mode for some reason
I realised that the reason why I haven't bothered to learn powerful keyboard-based navigation controls, is because I'm almost totally distanced myself from using a normal mouse. I love using MacBook Pro trackpad more, and I feel restrained every time I use mouse.
This also affects the amount of hand movement: the trackpad is a lot closer to the keyboard, so navigating with it doesn't bother me that much. In the long run, I'm sure that learning stuff like the author would be a nice boost, but I don't simply feel the need.
It's funny how people who know vim expect every other editor to have support for it's keybindings too, while I as a non vim user am expected to love and learn vim keybindings
I’m a heavy vim user and I love it, but that’s me.
I work with people who can navigate codebased absurdly swiftly and debug things faster than I ever could, and they use visual studio keybindings.
It’s all about knowing your tools; I’m a sysadmin so vim (Or, vi) has a high value for me as learning the keybindings makes me more powerful on my entire fleet.
For developers though? Debugging and codebase navigation is significantly more valuable- you read more than you write.
If you can't learn to love vim keybindings, you're not going to love vim; they are the primary selling point of the editor. Once you learn them you will want them everywhere. It's about wanting the best parts of VIM and an IDE (I don't think that has been achieved though).
Things look quite different in biostatistics research and adjacent fields. I personally use vscode, nano, and rstudio. But I am still mostly wetlab. People in my research group use some combination of these, maybe atom, and I am sure some of them like vim or emacs, but I haven't asked. The python guy uses vscode instead of intelliJ. I haven't seen anyone use vscode over RStudio, for R. But some of us will occasionally preference R intepreter in the terminal.
But it only works on what you can currently see, right? Or does ace jump work differently than I recall.
isearch moving you along further in the buffer interactively as you type is far more useful than searching what you just see, and typing rando letters that appear. If it's on the wrong entry with the same word, I just hit C-s again - which is very fast to type repeatedly (rather than ace's find the right letter combo, and type it).
I just wanted to note for the author, if they’re here, that VSCode has a newish plugin called neovim I think that actually uses neovim itself to handle movement and editing, so it should work no matter how odd the config.
I currently use VSCode and Doom Emacs, after being a fairly long time vim user, fwiw.
I stopped reading when they wrote that they preferred modal editors because they hate navigating with arrow keys. Uh, I use to live in Emacs and now I use VS Code, and you could remove my arrow keys for all I’d care (or notice). Those are entirely orthogonal, like “I prefer cars to bikes because I like tires.”
How do you navigate text in VSCode without arrow keys (and equivalents such as Pg Up/Dn, Home, End)
I’m not sure about the author, but I consider emacs essentially a modal editor. The vast majority of actions are preceded by a combination of modifier key presses, which is essentially modal, except you can’t (or can you?) keep it sticky.
So, for example, next line in Emacs is Ctrl+N whereas in Vim is Esc+J. The only difference in VIM is that you don’t need to hit ESC the next time want to go to the next line whereas Emacs reverts you to “insert” mode requiring you to press Ctrl again. But in both you can type out a number to allow you to jump 5 lines instead of just 1 with each key press.
Of course, those are only the in built modes. In many ways, emacs is even more modal than Vim, since there are so many packages that shift you into different custom modes With different behavior (e.g. org mode, magit, etc).
That's not modal though. You could make it modal/sticky with e.g. god-mode, evil-mode, or others, but essentially its a single shortcut (yes, it uses two keys instead of one, but that doesn't make it modal: try pressing Ctrl and afterwards pressing n like with esc h for vim, I don't think it'll work...)
Org-mode and magit are modes in the sense that they are different environments, not input modes. You won't have a good time trying to update your calendar using magit, and reverting the latest commit is going to be a challenge from within org-mode. These are different tools.
I'd say once again, emacs can be as modal as you like, more or less exactly like vim, or it can be non-modal.
All of the most common Emacs movement keys work in VS Code (^n, ^p, ^a, ^e, etc.).
I see what you're saying about Emacs's modes, but understand that that's a different meaning of "modes" than people common use when talking about editors. By the definition you gave, I couldn't really think of _any_ editor that's not modal in some way.
I'll crosspost what I wrotw about Doom Emacs on Reddit:
-----------------
> The killer feature of Atom to me is its ability to tell you what commands are associated (or erased) for a keybinding you are pressing, live. It is very practical to debug keybinding issues and I wish more editors had it. Other editors feature similar stuff, but not quite as good as this echo mode for keybinding.
Btw, for Doom Emacs this is accessible through the help interface.
`SPC h k <key combo>` will open up the manual page for that function, with a description, list of keybindings, argument list, and at the bottom, full code listing where you can jump to references including callers/callees and examine the code in-situ if you need.
`SPC h b b` will allow you interactive search through Doom Emacs bindings and bring up the same as above, and `SPC h b` exposes other neat things like keymaps for the current major-mode, etc.
---
Honestly, I have been using Vim constantly in various forms -- GVim, Vim, Vi, ex-vi, Neovim, etc. (Even ex and ed(1) for a little period) for about 8 years. I discovered Doom Emacs this July, and gave it a few hours. Then I kept on giving it a few hours. A week later I hadn't boot up vim for a week. With Vim, there was always a barrier around writing extensions -- it never really felt like it was meant to be integrated with them. The single best Vi experience I've had wasn't with Neovim, it was with ex-vi. There were some sharp edges but the interface felt orders of magnitude more clean than I was used to.
I had tried Emacs before but Spacemacs was poorly integrated -- I tried using package-install and I was dumped into a buffer with no evil-mode bindings. And learning Emacs was a hilarious nightmare. Just look at these amazingly terrible commands to know how horrible that was[0], the last straw was when I tried to undo using `C-x u` (I think?) and it undid one character at a time!
Two things sold me on Doom Emacs - the support, and the feeling I get when using it.
* The support is amazing, I can't even begin to comprehend how much the maintainer, Henrik, works at it. He has a well-developed system on the discord where you can hit up one of the assigned channels (how-do-i or troubleshooting are the main ones as a newbie), tag \@helpme, and you will get seen quickly. He stays up until 2 am some nights answering support requests, and has put a lot of work into `doom doctor` so there are some rudimentary diagnosics included. It is by far the most pleasant and memorable support experience I've ever had with any piece of software in the 10 years I've been programming, and I have a huge amount of respect for him.
- The feeling I get when using it is harder to quantify. I'll attempt to quantify the 4 or so years I spent digging into hacker history in the following comparison:
- Vim - Editing becomes muscle memory, so you don't need to think. You can sit down at a computer and be sure it has some variant of Vim that you can use almost like normal.
- Emacs - The editor grows around you, as you customize it to your taste. You're taking an editor built on a language, and altering the code, patching in improvements. Each Emacs instance is totally unique, and can rarely be used by another Emacsen (I actually vaguely recall reading/hearing of a joke where it was implied the Emacs instance and the beard grew into each other).
Doom Emacs, for me at least, is the perfect blend of the muscle memory interface power of Vim, and the "block of clay" feeling I get from Emacs.
That feeling while using it is very recognizable to me. It's like the cliché about swordfighting: the tool is an extension of your arm, rather than something you interact with.
I really like smart IDE’s like IntelliJ and pycharm. I’m doing a typescript project in VSCode and the refactoring and code understanding is just... not enough. I agree with James Gosling’s opinion of heavy IDE’s. They help me. I’m not out to prove any my manliness
Also, I feel like I do more reading code and debugging than writing nowadays, and I am not bothered by my speed at writing code.