Although I recognize that theoretically there are features in an IDE that could be useful, every time I've tried to use one I find it intrusive and slow and frustrating and confusing. I inevitably close it in a rage within 15 minutes.

neovim plus a couple extensions plus some Unix command line tools are just so simple and convenient.

Why did you spend time to figure out and set up vim, tools, and extensions, but only spend 15 minutes with an IDE?

vim's "design decision" to have extensions and external tools that you need to manually string together somehow is just as infuriating.

I feel pretty much the opposite. IDE's seem incredibly limiting and feature-poor compared to editors like vim and emacs, which can do just about anything.

Regarding your specific examples, both vim and emacs have file histories and if your files are under version control it's easy to get diffs.

Searches are super powerful in both vim and emacs, and it's easy to search across multiple files as well using various scripts/plugins.

The main downside to using editors like vim and emacs is that you have to be a pretty advanced user of them and spend a lot of time configuring them to really feel their power. If you've just dipped your toes in they're not going to look very impressive and you'll likely be disappointed.. but invest the time and they're very hard if not impossible to beat.

Can vim and/or emacs do refactoring? That is a feature that I use daily and couldn’t live without

Yes. Well, Emacs definitely can, and I have no doubt Vim can with the same tooling. For example, Emacs has excellent support for LSP. If a language server exists for your favorite language, and it supports refactoring, then so does Emacs.

You’ll find that most of what happens behind the scenes in vscode is available in neovim (and probably vim and emacs). The heavy lifting is done by lsps these days.

One notable exception is that neovim has treesitter, so you get immediate semantic analysis on your code which allows for much more flexible refactoring. Like everything in vim, you need to spend time setting these things up to streamline your common workflows.

Of course, both coc and lsp are your friends there. Want to change variable or function of class name or whatever? No problem. Take this piece of code and wrap it into a function, and where it once stood just place the function call? No problem. Etc.

Note that refactoring only exist for some language: for Java it exists in some IDE, for C++ no.

CLion absolutely has refactoring for C++ (perhaps not as powerful as for Java, but there is plenty).

Worth noting that debuggers, which frequently have complex interfaces, are generally much better suited to GUI applications.

Having a good debugger integrated with my code editor is basically the reason I use an IDE instead of vim. Stuff like Vimspector exist but are way more work to use vs. a GUI equivalent.

The gdb TUI with a simple config and a simple readline config from a terminal has personally done wonders for me. I get vi mode, tab completion, syntax coloring, a colored prompt and really all I could ask for. I have aliased gdb to "gdb - q -ex start --args" and the experience is very nice.

If your debugger implements the DAP protocol then Neovim is currently capable of a just-as-good debugging experience in my opinion.

The sole exception in my opinion is remote debugging (it’s not too bad, but JetBrains really bootstraps this part very well).

I think the interesting thing with debuggers, though, is that I relied heavily on debuggers back when I was relatively new to programming (maybe the first 10-15 years or so), but once I started to feel like I knew what I was doing--and the stuff I was doing became a lot more complicated--debuggers started to feel a lot less useful and even frustrating or limiting... particularly so given that to actually make a debugger work really relies on you buying your entire project into some unified concept of how execution will happen, as the ability to step across IPC/VM/network boundaries is otherwise a pipe dream. I thereby only feel like I get value out of stepping through some code only once every year or two, and gdb is more than good enough; otherwise, I always make sure I have really good mechanisms for logging and error handling, and leave the debuggers for when I'm teaching someone how to code.

This but less insultingly.

Eh, I'm pretty good w/ both gdb and pdb (python's debugger) and whenever confronted with an IDE's debugger (or Firefox/Chrome) I instantly feel like I do when confronted with an IDE: I'm at the mercy of whatever UX this thing will grant me. Scripting will be nonexistent/unfamiliar, specific information will be hard to find, etc.

I have a (maybe overbroad) critique of GUI software which is that it mostly brought us pixel-level graphics at the cost of extremely restrictive UX. Or said a different way, GUI apps look better but they're usually harder to get work done in.

Part of that is toolkits, part of that is you're using a mouse which is like driving a space ship with a single finger, part of it is the expanding user base of computing (to people who don't necessarily want to learn say, regular expressions). But like, I script GDB. If your IDE debugger won't easily let me do that (or it will but it's a painfully convoluted UX), it doesn't really matter to me that it (subjectively) looks nicer.

Just my 2 cents on this

> I don't quite remember something and having the internal file history with a diff readily available.

You're already in a terminal, git is just one command away

> Some of the click and find implementation/usages never seems to quite there to me.

This really depends on the language you are working in, but generally vim's gd (and plugins that augment it) enough most of the time, otherwise grep/rg if you know what you are looking for. If you are using something really dynamic, e.g. ruby, then you're pretty much shit out of luck.

> I could go on, if you're truly being productive and not missing out on feature, more power to you.

Here's the thing, the best part about it vim is that it is not slow (plus paired with a terminal emulator like kitty/wez/alacritty). When I type the characters actually appear on the screen as I type them. With most IDE's (at least the ones I have used) there is a noticeable delay from when I have stopped typing and characters appearing on screen.

Another thing to add is that vim is very fast to start up and shut down, I open and close vim multiple times as I am working. With an IDE, startup times are atrocious and dont really fit my work style of cd'ing somewhere quickly editing something, cd'ing somewhere else and rinse and repeat.

In general I find the original command line tools to be much better than IDE provided equivalents or integrations, there's no unnecessary animations and much less cpu/ram usage. Though one exception for me is the database clients, where I much rather prefer a GUI than using the CLI client.

Your tests are already runnable from command line (assuming CI is setup).

Basically, Unix becomes your IDE

> Here's the thing, the best part about it vim is that it is not slow (plus paired with a terminal emulator like kitty/wez/alacritty). When I type the characters actually appear on the screen as I type them.

I just noticed that ~/.vimrc adds a small delay, even if it is empty. This is the test case:

Create a file with about 10 emtpy lines and type:

    esc                 switch to normal mode
    gg                  go to the top
    ctrl + v, G         select all lines
    shift + i           switch to insert mode
    - line              just type something
    esc                 this will duplicate the first line until the end of the file

If you repeat the test case with no ~/.vimrc, you will notice that the lines are changed faster.

Having a ~/.vimrc, even if empty, sets 'nocompatible'.

"When I type the characters actually appear on the screen as I type them"

Great quote. Perhaps one of the best arguments for using Vim

IMO it’s because you’re conflating vim with an IDE. But really it’s unix that’s the IDE. I’ll use vim to literally edit files, and then in an alternative tmux pane either run my tests or ‘entr’ my source or ‘rg’ to search or git —-bless or whatever…

Editor + shell + tools is the IDE. And I like that I can swap out tools as necessary.

And should you want to do any of that from vim, you can (and you can customise it exactly how you want).

I've used vim for a while now and using it isn't a point of pride, it's more that whenever I try an IDE I wonder how anybody could be productive using it.

I've rarely had a problem with search, I can type `:grep [some regex]` and I'm quickly shown all matches for that regex in the entire project. I admit I'm not sure how I would do a more complicated query, but this is almost always enough, what kinds of queries do you do which this doesn't cover? There's just one exception, I'm currently working in a codebase where members have very generic names, `Nonce` is a valid field name for a number of different structs, which makes search results for `Nonce` tedious to work through. For this situation I've added a keybinding which calls semgrep and lets me view all references for a specific struct's `Nonce` field.

Calling out to semgrep is an instance of a more general pattern: Because vim is not integrated I lean on tools outside of vim when necessary. The `git` cli, especially once you add some aliases, gives fine access to file history and diffs.

The feature I'm most jealous of is debugger integration. `gdb` and `dlv` get the job done but it's really convenient to be able step through your code with the same interface you use to write it.

> There is also the point of being able to use vim bindings inside of the IDE

Every vim keybinding re implementation I've tried has been missing essential features. When I'm inside an IDE I spend much of my time typing and navigating. When I'm inside vim I'm _thinking_, and the necessary changes occur about as quickly as I decide upon them.

About :grep, try integrating GNU id-utils with Vim.

GNU id-utils provides a mkid command which scans a directory of files to build a binary index file called ID. The lid tool is used to query this and provides a grep-compatible mode.

lid sometimes puts out things in a funny order, so I sort the output.

  :set grepprg=lid\ --word\ --result=grep\ '$*'\ \\\|\ sort\ -n\ -t\ :\ -k\ 2

This is basically instant even on huge file trees.

Or, if you'd like :grep to use git grep:

  :set grepprg=git\ grep\ -n\ '$*'

What do either of these `grepprg` options win me? Currently my `grepprg` calls `ag` which is plenty fast for me, and it sounds like `lid` is a slightly more general ctags?

lid doesn't tell you where an identifier is defined, but indexes all the places where it occurs. A lid query is instant; it just pulls the info from the ID file without searching any files.

In a large-ish project like the Linux kernel tree, there is no perceptible delay.

I use ctags in parallel with mkid; different tools for different job.

Speaking of :grep, I have it mapped to the K key.

The default action of K is to do a man page lookup of the word under the cursor. I changed it to grep instead. ... and I preserved the man page functionality too. The default K takes an optional prefix (man page section). I have it so that if I give a numeric prefix to K, it will do the man page lookup for that section:

  :nmap K "_y:execute count ? ( ":!man " . count . " " . expand("<cword>") ) : ( ":grep \\<" . expand("<cword>") . "\\>")<CR>

and for grepping for a visual selection:

  :vmap K "zy:execute ":grep " . getreg("z")<CR>

I don’t use debuggers myself, but I think they’re pretty well supported within vim (neovim at least) these days https://github.com/mfussenegger/nvim-dap

Vimspector: https://github.com/puremourning/vimspector

On search:

IDEA out of the box has:

- fuzzy text search across your entire codebase. Supports regexes, when you need them

- fuzzy text search for symbols only (e.g. when you only need to search for method names etc.). Supports regexes, when you need them

- fuzzy text search for file names

- Ctrl/Cmd + click, or Ctrl/Cmd + B on any symbol, and you'll get a list of all the places where this symbol is used (e.g. a method name that's called from various places in code, including test code)

No extra plugins, or setting up keybindings, needed.

With vim though... Even discussion on search devolves into listing which tools everyone uses, with which options, and a discussion on how circumvent their limitations.

Edit: esp. with search almost every year there's a new tool that you absolutely must use because it's better than the previous tool. ripgrep, ag, telescope, treesitter, semgrep, use them all!

IDK grep and find work fine for me here.

> Edit: esp. with search almost every year there's a new tool that you absolutely must use because it's better than the previous tool. ripgrep, ag, telescope, treesitter, semgrep, use them all!

Aren't you also doing this? "Use IDEA, it's great for searching!".

I think there's something to be said for aesthetics here, where if you like typing you're gonna be into the grep/ripgrep/find aesthetic, and if you like GUIs you're gonna be into IDEs. People trying to assert some kind of objective superiority of their tools over others' is kind of tedious. Use what you want.

I was contemplating the same thing today as I was knee deep in refactoring a piece of code - I use IntelliJ and ideavim, which I find great because it also implements (emulates?) a small subset of vim plugins. I was able to finish the fairly complex refactoring in half an hour, without taking my hands off the keyboard by using a fairly strong combination of vim and IDE features. This is what works for me.

I use an IntelliJ plugin that notifies me when I could’ve used a shortcut but I clicked with the mouse instead. It also counts the times I missed a shortcut. I keep a pretty low count but I was watching a colleague that had the same plugin and he had missed a certain shortcut 22k times. He is as productive as I am, so to each his own

What is with this obsession of never taking the hands of the keyboard? I've seen it so many times and it makes no sense to me. I don't find myself limited by the speed of typing but by the speed of thinking.

Neovim user, so a little different. I used to regularly use GoLand for ~3 years before I made the full switch over, and am a bit of an evangelist of it.

I'm simply faster in it. I'd probably say the initial main attractor was modal editing (vim-mode plugins in Jetbrains are not my favorite - usually not a full implementation of the real features vim offers).

* For syntax highlighting: tree-sitter is as good, if not better in my experience.

* For auto-complete/navigation/etc: LSP support + a small few plugins solve this, running on par with what GoLand offers.

* Search support, like the case you mentioned - I use Telescope + Ripgrep and usually my searches are roughly the same time to process as GoLand did.

Are there other features that are drastically important? Because the other features Neovim offers over GoLand are:

* It's way faster to load. Indexing in GoLand takes so long. LSP servers do usually take a bit of time to index but this is on the order of minutes faster than GoLand takes for the projects I have to use at work.

* Significantly less memory consumption.

* I can be purely keyboard driven.

* Modal editing and all the niceties that come with that (note: emulators are always subpar in my experience).

* Being already in the terminal is a significant advantage, especially on my laptop screen (less-so on my ultrawide).

* Customizability is a lower priority, but it is still worth mentioning - there's only so much you can do to customize a Jetbrains editor.

I am far more productive using it than I ever was with GoLand. I might make the exception for IntelliJ when I used to do Kotlin work - but that's the exception, not the rule. For every other language I definitely prefer Neovim.

I think, like all tools, it's important to spend the time to learn it (if you desire to actually use it). Otherwise, of course vim will just look like some archaic tool that seems like it lacks all modern support.

Treesitter is amazing. We have a bunch of sql strings in python and I was able to drop a couple of lines into my injections.scm to isolate them and get perfect sql highlighting within my python code.

I didn't even know you could do that, this is why I come to this site.

If anyone is interested in how it works, here's the whole thing (I'm looking for strings inside a call to a text function, which is how you wrap sql for sqlalchemy).

    # queries/python/injections.scm
    ; inherits: python
    
    ((call
      function: (identifier) @_func
      arguments: (argument_list (string) @sql))
    (#eq? @_func "text"))

There's a little nuance here where the thing that treesitter parses includes the """ (or ") at the start / end but because it can recovery from errors I'm not bothering with wrangling the offsets.

This is something I've been thinking about a lot recently, especially since listening to John Carmack interview (https://www.youtube.com/watch?v=I845O57ZSy4) and him saying that almost nobody uses IDEs at Meta.

I think it is totally possible to be (even very) productive in VIM. I do think, though, that a person who is productive in VIM would be more productive if he used a proper IDE.

This is my experience after I had been using VIM for about 10 years and switched to an IntelliJ IDE (and actually learned it)

(This, of course, assumes that there is a proper IDE for your language)

> that a person who is productive in VIM would be more productive if he used a proper IDE.

What features does a "proper IDE" offer that, at least Neovim, does not or cannot provide?

Complex IDEs offer a promise (backed by $$$).

Class hierarchy visualization, database schema mappings, the latest & greatest in NLP & code completion via plugins. That "just works."

Ultimately, a sufficient amount of configuration adds all those things to Vim/Emacs. Ditto VS Code on a smaller scale.

The issue is how much time.

I use all the obscure features of IDEs. Navigate to next issue, bookmarks, you name it, I've got it, for large codes.

Implementing... all... of the features Intellij/Rider provides out of the box for JVM/React stack in Vim is... an undertaking.

Don't get me wrong. I love SpaceVim, and if I worked in a domain like firmware, I'd be far more comfortable with it.

Maintaining a Vim config that's integrates every tool I need for JVM and React (and machine learning, and all the other domains) is impossible.

When I need an interactive debugger, I alt-tab into a JetBrains product or VS/VSCode. The only time in my career that I wasn't primarily developing inside of vim/neovim and now Emacs was when I was working on a .NET team.

Why did you switch from vim/neovim to emacs?

I wanted magit and org-mode.

You have to invest time in your vim setup. There’s a whole lot built in that you need to learn, but you also need to customise it to your workflow.

In terms of searching through multiple files, I use Telescope with ripgrep and fzf. It’s an insanely slick workflow that allows me to jump around code faster than anything else I’ve used in my last 25 years of coding.

This, 100%. It took me an hour the first time I configured neovim and another hour when everything broke during the v0.8 update but the ability to navigate multiple files without touching my mouse make it worth the effort. I still have to use Visual Studio for {dayjob} but the Vim binding plugin makes it (almost) tolerable.

The icing on the cake is when I need to SSH into a server to debug some PHP or JS on a testing server. I know I can always open Vim for a slightly degraded (compared to my Neovim setup) but overall solid editor at any time.

Regarding the last part of your comment: you may get some value out of this plugin, https://github.com/chipsenkbeil/distant.nvim, https://www.youtube.com/watch?v=wVAsbpByQ3o.

I've not used it but your use case made me wonder if there's a nice way to do it, as I regularly SSH into my NAS and RPi's, so I had a quick search.

IdeaVim in the jetbrains products is really good I find. You get best of both worlds. I used to customize vim a lot, but I pretty much just use it as is now as a casual editor for editing files, especially for big files. The editor is very snappy and quick to load compared to IDEs, but on a well spec'd computer you aren't really going to notice too much (depending on the IDE)

> It's alway pretty fascinating to me that people can actually be productive without an IDE.

I was coding for years before I discovered that IDEs exist. Never used one much until I started using VS Code a few years ago (if you call that an IDE, some people do and some don't).

vim, grep, and find. git-grep turns your codebase into a O(logn) database

There's a steep learning curve, and it's not necessary. I mainly use Vim, but it wouldn't be a big deal if I didn't.

Reasons for me:

- It's a lot more laptop-friendly not having to deal with a mouse and complex GUI. I even gave up my desk at work and just sit and code in random places.

- On my desk at home, it's a bit faster for me than an IDE. But that depends.

- Seems like IDE users are constantly switching tools, especially when changing jobs. Even at my current 4-year job, my teammates have all changed between 3 different IDEs and had to screw around with remote access problems for each. I've used Vim everywhere since college.

Its more of a focus thing for me. Its easier to get into the zone when I'm in a terminal with no mouse and all the GUI noise stripped away.

I'm sure I'm missing out on quality of life enhancements and whatnot, but really all of those are lower on my hierarchy of needs than staying on task.

From my perspective, vim is just a tool that I picked up in college, back in the bad old days (early 00's) where good IDE's were paid and anything free was largely terrible.

Sure IDE's are great, I love stepping through code, it really helps when you're in deep and are having problems reasoning about the state of your program.

That said, every shop I've worked in used a different IDE. Possibly one picked out by some long gone coder who thought that their choice was the best.

Finally not being saddled to any one IDE lets me use the any other tool to get a job done.

I suppose I agree with this, I try not to obsess over the tools too much. It makes sense to have a standard IDE and standard tools in the company. However it's always a possibly to improve. One can suggest new tools to a small circle of coworkers, or just start using them on one's own. In most situations it's possible to install and use vim as an accompanying tool. In one workplace that has a huge Windows codebase I compile and debug from within Visual Studio, and edit either in Visual Studio or sometimes vim. When I get the chance to do explorative work on a rather standalone project I gravitate towards vim, even to printf debugging, even though Visual Studio is available. I don't know why this is, old habits, or is it genuinely more economic on some axis?

the main thing that allows me to be productive with "only" vim is, funnily enough, things outside vim: bash knowledge. search, for instance, I can usually do in flexible ways with a pipeline of commands.