I am writing this from emacs experience (some if not all these features are in vi as well), there are features from emacs that make a real difference in writing programs especially:

* Unlimited yanking from kill rings: ie pasting text from history of the clipboard.(This is one thing I have most difficulty with when switching from emacs to modern editors)

* Macro recording and playback : recording an arbitrary set of edit operations and then replaying them any number of times.

* two or more code frames/windows side by side, even displaying the same file Surprisingly modern IDE guis seems not designed for it, eclipse can do it but clumsily.

* Remote file editing: use the IDE tools to edit file residing on another computer.

* Column edits or rectangle edits. Selecting a vertical column or rectangle of text and copying, moving it to another place.

> some if not all these features are in vi as well

I'm not sure exactly which vim features are also in vi. Vim has been a daily use tool for me since about 2007.

Vim has really good Macro recording. Vim + Tmux is great for side by side code frames, and there are plugins for showing multiple buffers in one Vim instance. Remote file editing is good with SSH + Vim. Vim has multiple registries for yanking/putting. Vim has column editing functionality.

Almost anything Emacs does out of the box Vim can do with either a plugin or with an external program pairing. I prefer Vim's keybindings because there are less "chords" (Ctrl-C and Ctrl-V are copy and paste chords, they requiring pressing two buttons at the same time). Too many chords causing my pinky fingers to become tired. Vimscript is a surprisingly powerful language for dealing with text data, but it's cryptic the first decade you are exposed to it.

EDIT: I'm more interesting in the code people write than the way people write it, but I wanted to share some of my vim knowledge and point of view.

Unless I've misunderstood, you can use splits to show multiple buffers in Vim without any plugins.

What about manipulating of splits, like converting vertical split to a horizontal split, enabling/disabling synchronized scrolling, etc..

You can do both of those things in vim. I don't mean to be nitpicky, I'm just mentioning in case someone reading this didn't know and uses vim. You can set scrollbind and convert splits (off the top of my head I think it's Cw Ch and Cw Ct).

Remote editing, I mean using the local computer's emacs to edit file on the remote computer, where emacs does all the work of fetching and syncing the file (using ftp, ssh etc) back to remote. I think vim can do something similar too.

Friendly reply -

> Unlimited yanking from kill rings

vi has named buffers, which aren’t the same thing you’re talking about, but definitely more than a single clipboard

> Macro recording and playback

vi can “execute a buffer” which are arbitrary commands, and at least nvi can do automatic substitutions as well in a “dumb macro” sort of way

> Two or more code frames...

Same for vi. In nvi it’s :E for vertically stacked or :vsplit for side-by-side. Like emacs, you can even run an interactive shell in a buffer (frame) and cut/copy/paste with another.

> Remote file editing

I presume you’re talking Tramp. Not out of the box with nvi, but it interacts with the Unix shell fantastically if you’re lucky enough to be developing in such an env. I’d be surprised if vim doesn’t have a decent Tramp-like feature.

I think vim does columnar edits, but I’m not a vim user; nvi is out of luck there, unless again one finds a solution punting to the shell - which isn’t the end of the world. But this case I think would disappoint you the most from your feature list (speaking for nvi).

All of these features are also in "graphical" editors, despite the claims. M$ had been doing it for decades.

I remember a friend of mine showing how easy it was to block select in vim. I waited 30 secs or so. I showed him the same in visual c++ (circa 2000s). We then had a "vim-off". eg. Find/replace/regex across a range of things -- using only the keyboard. The best I conceded was how the highlighting of results was probably superior... (sublime text, and vs code are as good as that now)

I know a lot of people here love vi (and Emacs), but personally, the only command I'm happy to learn is :q (and I presume negative karma for this comment will result) :D

I always install le for my terminal connections, and fall back to nano where needed. I've been meaning to write a console editor of my own that matches ye-o olde vc++ and visual studio...

I think there's something in the vi evangelism that I haven't quite grasped... otherwise I'm sure I'd have been using it for decades.

edit: not sure about the yank/ clipboard history... but that's part of the os in gui world.

> two or more code frames/windows side by side, even displaying the same file Surprisingly modern IDE guis seems not designed for it, eclipse can do it but clumsily.

It's embarrassing how much better emacs/vim/tmux/others are at windowing compared to supposedly advanced IDE's built on advanced windowing systems.

> And I know devs that swear by vi...they are developing any faster than I am

I hear about this from time to time, but have never seen it people do it successfully first hand, what I do see is silly mistakes in their checkins; incomplete variable renames, formatting is off, syntax errors, switching between browsers and their code while looking at manuals, or other obvious mistakes that can be caught inline by IDEs while you type.

I think this says more about those developers than it does about Vim. In my experience, people who are highly effective at programming in Vim typically have it configured in such a way that it offers language-specific functionality comparable to any IDE. You don't get that out of the box (unless you use a Vim distro), but you are able to personalize it to your workflow more exactly than you can with an IDE. A junior developer probably isn't going to be more effective in Vim than an IDE, but a very senior developer easily could be. And somebody who is committing code with lots of obvious errors is almost by definition not a senior developer in my book, regardless of whether they're programming in nano, Vim, or an IDE.

I see the same thing from people using vscode. Its safe to say that those who know their tools well will be more productive than those who do not.

I think VS Code has the same issues I see it with that too, I haven't noticed it as much with VisualStudio and JetBrains' IDEs. Agree completely on knowing how to use your tools, it's like a carpenter showing up for work with a rusty hand saw and thinking they're going to make a house with it.

Hmm, I've got syntax/compile checking, linting, automatic code formatting and generation, and code completion based on context in vim right now. I don't see how any of the problems you mention are vim specific.

What packages are you using and what language out of curiosity?

C++ and JavaScript. I've got about 60 plugins installed and a highly configured vimrc. Some of the important ones:

w0rp/ale

junegun/fzf

junegun/fzf.vim

majutsushi/tagbar

scrooloose/nerdtree

jistr/vim-nerdtree-tabs

erahhal/nerdtree-ack

tpope/vim-commentary

joegesualdo/jsdoc.vim

Raimondi/delimitMate

tpope/vim-surround

vim-scripts/AutoComplPop

Shougo/deoplete.nvim

carlitux/deoplete-ternjs

marijnh/tern_for_vim

Rip-Rip/clang_complete

SirVer/ultisnips

tpope/vim-fugitive

mhinz/vim-signify

vim-scripts/DirDiff.vim

sheerun/vim-polyglot

pangloss/vim-javascript

vim-utils/vim-man

That's a useful list, thanks for sharing. What would be useful is if there was just a distribution of Vim that just had everything included for a specific language. Or at least a base and then a way to discover and add more from within Vim.

There are definitely distributions, for instance SpaceVim. I've got my own configs shared in GitHub but I'd prefer not to reveal my identity. I'm sure there are plenty to be found.

There are plugins made for a language, but they are usually bloated, it's cleaner to compose smaller plugins to achieve the same outcome.

Usually vim configs are like toothbrushes, everyone uses a special one. Here's mine that includes dozens of plugins, some of them repeated from colordrops' list:

https://gitlab.com/somini/dotnvim

Most of the things you're describing as editor issues would be caught by formatters and linters and a test suite, so I have a hard time understanding where you're coming from with this.

edit/ A word.

This is a good point actually, the sooner you catch the mistake the quicker you can correct it. So once it gets down the line, even in a pre-commit, you're just wasting your own time on getting the feedback. It's not always possible to get it sooner of course.

Yep. I have formatters and linters run on save in vim (of course, any editor or IDE can handle this) and the linters render their results in vim, as well. I also use vim-dispatch [0] to handle running builds and test suites asynchronously, but I don't run any auto commands for that, instead preferring to kick those tasks off with a keystroke.

My workflow is crafted in a way to give me, what I have found to be, the tightest feedback loop that I can possibly get with the languages and frameworks and tooling that I use at work. I find that vim, out of every other editor or IDE that I've ever used, is set apart in it's ability to deliver on that requirement.

[0]: https://github.com/tpope/vim-dispatch

At any rate, it's a good thing that literally every single IDE can do search and replace with regexes.

> but I never want to be in a place where I have to regex my code...ever).

I use regex search and replace fairly often; why are you so opposed to it?

If I need to change $t1 into t1 in a group of 6 lines (something I did today), its pretty easy to just make that replacement automatically. Doing it by hand would just take longer.

> ... with an occasional refactoring

That's exactly what I use the feature for.

In a refactoring IDE, you never risk overmatching or under-scoping. You just rename the syntactic object and it's renamed exactly where it needs to be, including possibly on the filesystem and in git.

Importantly, you don't get that safety in comments or strings.

The nice thing about replacing via vim is that you can restrict it to a selected block which also gives you a type of safety.

Particularly for the situation I used replacement today, an IDE couldn't make it better and doing it only on a range was helpful.

Fair enough. An IDE will generally present you with matching strings on a project level and let you select which ones to change. But if you know where to look, replace within selection seems useful. Apparently IntelliJ supports that, but I've never thought to use it.

If you're still working with VS & Resharper and your projects allow you to, have a look at Rider from JetBrains. It supports the same color scheme & hotkeys as VS + Resharper out of the box so the transition is very smooth, you'll be productive in minutes after installing it. Also, if you were using VsVim, you can use IdeaVim for Rider and in addition you can install KJump plugin (it's what easy-motion is for vim). Since setting this up, rider & webstorm have become my favorite developer tools I have ever worked with and I feel they are superior to VS & VSCode (the things I was using before).

First, I also had trouble with XCode. About the regex in vi: there is a technique of writing/maintaining code based on substitutions instead of inserting/deleting. It can be very powerful but you have to "write" your code thinking about the patterns and maintaining some kind of structure. I am not saying that it is good or recommended. It's interesting. I coded for like 5 years like that. I was maintaining a codebase completely solo. When working with a not very synchronized team or having tools like resharp or omnisharp etc avaliable, I don't think it would pay off.

Searching with regexes is more likely to be useful when trolling through log or data files than code.

Even then, the most common cases for me are searching for a string only at the beginning or ending of a line, or only searching for instances that are not part of a larger word.

I search for /def.*partial_name/ frequently when I can’t quite remember what a method is called in Ruby.