Hacker News new | past | comments | ask | show | jobs | submit login
Why I teach vim (ceos.io)
152 points by amichlin 5 months ago | hide | past | favorite | 180 comments



"I wish I could say I agonized over all the options at the time and decided vim was the best pedagogical solution, but the reality of the situation was that vi was what I used in college because my father taught me vi"

We dont talk about this much, but many of us hardcore Vi/Emacs users have had this knowledge imparted to us from a mentor. Thats probably why the use of Vi/Emacs is much higher in established tech environments (universities, big dotcoms), where there tends to be a tradition of mentorship than it is elsewhere. If anyone is looking for a slightly off-the-wall masters thesis, I'm fairly certain that you could extrapolate this out into a class divide- perhaps richer/more-established/well-educated users are proportionally more likely to use Vi/Emacs, and in some ways use them as "gatekeeping" tools?


They're not really the same thing, compared to vi[m], emacs is statistically dead. And there are already lots of people who're well into their careers in academia and industry who aren't users of either.

My own contrarian and probably equally wrong take is that it's mostly about accepting the (evidence-free) premise that modal editing is actually a good thing. It's hard, you suffer but lots of smart people tell you it's worth it and perhaps your suffering will help you be as smart as them. It ends up being closer to hazing and penance (your editor as hairshirt) than actual gatekeeping.


The "suffering" has honestly been overblown by jokes about not being able to quit on one side and the mythologizing of the leet ninja 10x programmer who is only bound by his typing speed and can't waste time reaching for the mouse, on the other side.

It continues to surprise me why people have such strong opinions about someone else's editor choice. My current theory is vim users are like vegans/gluten free/paleo/etc, in that its a personal choice that some are public about, and people love to hate on it and "disprove" it for the same reason.


I suffer every time a linux distro has nano as the default editor. Cant save a file, cant exit, have to read the two bottom rows and figure out those alien shortcuts. yuck


Those alien "shortcuts" are Emacs bindings, the same as in a Bash shell, or a Cisco router etc.


I did use emacs before i switched to vim 15 years ago. My memory is hazy, but i am pretty sure Ctrl-O to save a file and Ctrl-X to exit are not emacs bindings. I was as confused with nano when i used emacs as i am now.


yes, some bindings may be different for meta-control like you are pointing out (the editing ones are Emacs)


> The "suffering" has honestly been overblown by jokes about not being able to quit on one side and the mythologizing of the leet ninja 10x programmer who is only bound by his typing speed and can't waste time reaching for the mouse, on the other side.

You're neglecting the folks who use keyboard editors (and fancy keyboards) to reduce the incidence of RSI.

If I can accomplish the same tasks in four keystrokes (~1s) as it would take me in a dozen clicks and 15 seconds of mousing, then poorly designed programs forcing me to use the mouse to interact are causing an order of magnitude more strain than those designed for keyboard interaction.

(This is less an issue in text-editors, and more an issue in everything else user-facing.)


I'm responding to a user who described having to learn a text editor as suffering. I'm not sure how your response relates to mine.

I happen to be a person who uses a fancy keyboard (Kinesis Advantage2) and text editor (vim) to reduce RSI.


> My current theory is vim users are like vegans/gluten free/paleo/etc, in that its a personal choice that some are public about.

This is not a good theory. Surely, this effect appears wherever you've got conflicting choices about what is best, but there are always reasonable arguments on why you should do X over Y. And you know, there are always people who respect other's choices.

I am a vim user and I 100% understand why others don't want to get into it. I don't bully them, I will explain only once why I think it is a better environment and then they are free to carry on with their lives and so am i.

People who are extremely attached to their choices are (to me) unable to understand that every tool is for a job && different people have different needs. This shouldn't lead us to label a group of users and ignoring the pros and cons of smth


I am curious if any vim user has ever been able to see the benefits of other environments. I know I have never been able to see the benefits of vim. Part of me wants to give a try for 3-6 months just to prove to myself that it's all bullshit and that vim is just another editor.

In any case. For a long time I was a fan of my editor of choice, slickedit. It definitely has a few features I use for which I don't know the analogs in most other editors. Features like versions backups. Undo of multi-file search and replace.

Also once had someone show me IntelliJ for C++ and was fairly impressed with its refactoring features. Enough that I thought I should look more into it.

I have yet to see a feature for vim that makes it clear win over any other major editor. I have read articles that make me understand why others might like it but seriously. I think you're all deluding yourselves.

Just as an example, lately I mostly do JavaScript and a little typescript. I'm 100% sure that the VSCode experience there out of the box is superior to vim for the same purpose. VSCode is node aware, browser aware, npm aware, eslint aware, typescript aware out of the box. I have no idea how much configuration I'd have to do in vim to get it to match and I find all of that invaluable. I'm not saying vim can't do it but I am saying if I tried to start using vim today on the projects I'm working on the experience would be seriously inferior. I don't know what language I'd have to be using to change that.


I'll bite; I'm real good w/ Vim.

My thesis, which is a borderline polemic, is that if Vim doesn't suit your needs you are doing it wrong. If your program/language/environment needs a smart editor, you've built or chosen a program/language/environment that is too complex, and an IDE won't ever solve that fundamental problem. I get we don't always get to choose these things (wh o hasn't had to learn React, Typescript, or the general JavaScript ecosystem) but my cultural stance is the people who made those things should have used Vim, realized it was hard to manage w/ Vim, and questioned their priors.

That might sound nuts or the ravings of someone who's completely drank the kool-aid; who got good at one difficult thing and now like, jams it in everywhere to ladder pull or whatever. And so I should say that I'm super amazed by the capabilities of IDEs like PyCharm or even Eclipse (or, honestly, even Code::Blocks). The sheer engineering effort alone is awesome, but some of the stuff you can do with them is incredible. I can't imagine developing the source code of Eclipse with Vim. But does using an IDE to develop Eclipse make Eclipse great, or does it simply make Eclipse _possible_?

I contend Eclipse shouldn't exist, at least not in its current form. It's too complex for humans, and its design necessitated so many engineering hours it was a net loss for humanity. If the complexity of your program/language/environment rises to the level you need an IDE to manage it, the only thing to do is start over.


Just to reassure you, you are not alone and I share this feeling exactly. It would worry me considerably if I could not use a generic text editor to work on some project. I would feel that the battle against accidental complexity was lost right from the start.

Fortunately, it never occurred, even when complex Java or Javascript frameworks were involved and coworkers thought specialized IDE were mandatory.


hmmm, if I apply that logic in other places it doesn't seem to work.

* if you can't cook with just a knife then it your food should be redesigned to need only a knife.

* if you can't film in with a camera then you should rewrite your movie (no CG).

* if you can't send it by paper then it should be re-written (no animation, no interactive diagrams, no apps)

To put it another way, I'd much rather use Final Cut Pro or Davinci Resolve to edit a video than FFMpeg. If someone became an expert in editing snippets into movies with ffmpeg from the command line and then told me that writing movies that require lots of editing is just bad writing and that it would be better if I wrote my movies so they required as little editing as possible I'd look at them funny.

Isn't it possible building up the system is a force multiplier in the same way that all the examples above the false restrictions prevent lots of progress?


It's not about force multipliers in general. It's about looking at what force multipliers incentivize/deincentivize and amplify/muffle.

With your examples, I would say something like:

OK I once only had a knife, but now I've invented an egg beater. This will allow me to do some things a lot more easily like:

- Bake cakes

- Eat soup

This will also mean I cut myself a lot less when I do decide to do something like eat soup.

So we're gonna have more cakes/soup in the world. Good? Great, egg beater stays. Bad? Woof, burying this thing in the yard. But wait I hate cutting myself. OK I'll figure out some other way to keep myself from gorging on cakes, or I guess be content with that.

So, broadly it's about thinking systemically--how the design of our tools affects how and what we build. Because it definitely has an effect. If it's easier to use a nailer than a screw gun, guess what, you're nailing more stuff. If it's easier to write a PRECONDITION clause in a function definition than a unit test, guess what you're writing a PRECONDITION clause.


You should read about the language server protocol. As it continues to become the standard vim will match most IDE-specific features while keeping all the benefits of using vim, which if you can't see I won't bother listing here. I'm already working on java 100% from vim and I don't miss a thing from intellij


Would you mind elaborating a bit on that for those of us not in the loop, like myself? Which plugins are you using?


Not the OP, but the plugins you want to look up are ALE and coc.

I've used ALE for a while and love it, but coc is the new kid on the block that often shows up in discussions of LSP.

ALE is very tunable, so it's good for us performance-nuts who don't want anything slowing down their editor without their permission.

coc takes a more batteries-included approach, and will allow you to hit the ground running / see the light sooner.


From my perspective there are two sticky elements to vim, where once you’re accustomed to exploiting them, you find it very difficult to leave.

The first (chronologically speaking, for most people) is modal editing. Most popular editors today support vim bindings. So this bulwark is gradually eroding.

The second is the automation. Any piece of your workflow can be captured and remapped to a couple keystrokes.

Some other editor might innovate a new feature that vanilla vim doesn’t have (in fact this occurs regularly).

The (not unique in idea, but in implementation) power of vim is not any superficial feature, it’s the meta feature of extensibility, and how this is interwoven with the modal editor idea.

I think many people who come to vim and then leave it for another editor get the first idea, but never got used to the second idea, or never got around to integrating the two.


> Any piece of your workflow can be captured and remapped to a couple keystrokes

How is different than recordable macros in 90% of the other editors out there? (vs programmable macros).

Can you give me an example you use regularly


Sure! One example is vim-dispatch, which provides a convenient interface for executing arbitrary shell commands asynchronously.

It works wonderfully with make, so you can run “make $file” in a couple strokes. I use this when writing markdown (to generate html with pandoc), editing test files, etc.

Another example is when I’m “cleaning” a large csv file. Most times, I can record my movements cleaning a single line, and then replay those actions N times. You could do the same thing with a regex sometimes, but for really complicated files this is easier.

A final, simpler one: I have <Leader>f mapped to fd piped into fzf piped into open. Other editors probably have fuzzy file finders. Some of them maybe even use fzf internally.

But I think this example demonstrates how vim embodies UNIX ideas, as a modal text editor that depends on other binaries for complex behavior. People levy this as a complaint, that it doesn’t come feature complete, but it’s in reality a strength. Because while other editors wax and wane in terms of features and performance, vim only ever gets faster, as the binaries you depend on are swall out for better replacements every couple years.


Unfortunately I'm not understanding what makes vim special here

> It works wonderfully with make, so you can run “make $file” in a couple strokes

I can do this in any editor I've ever used

> Another example is when I’m “cleaning” a large csv file. Most times, I can record my movements cleaning a single line, and then replay those actions N times.

I can do this in most editors I used (VSC being an exception). I use recordable macros all the time to clean up lines in emas or slickedit or any other editor that has recordable macros

> A final, simpler one: I have <Leader>f mapped to fd piped into fzf piped into open. Other editors probably have fuzzy file finders. Some of them maybe even use fzf internally.

Can do this in every editor I've ever used too.

Any actual vim only examples?


To clarify, I don't think these (or any) features are "vim-only".

I was intending to say that it's the meta-feature of vim that vim-users find so sticky, that you can trivially write your own features: composing arbitrary executables and modal editing.

I think most editors nowadays are taking a page out of vim's book, by exposing increasingly lower-level interfaces to extension authors and users.

In these ways, I think editors are converging with vim, over time. Vim (and emacs) has been this way forever.

You don't have to wait for the editor-making company to accept that your strange request is valid, you can just hack it on yourself.


I've had all those features in every editor I've used since the late 80s so no, no one is taking a page from vim or emacs.


And don't forget regex uses!


> I am curious if any vim user has ever been able to see the benefits of other environments.

Yes they can. Let me list them: 1) Familiarity 2) Ready out if the box, less effort 3) For specific languages and projects, you can't do it vim. Javascript is not one of those. Maybe android development is.

> I am saying if I tried to start using vim today on the projects I'm working on the experience would be seriously inferior.

Correct, it would be a BIG pain, and I know because I have done it. It sucks hard. But if you suck it up and start molding this extremely flexible editor to your needs, after a few months you will get a far superior experience than your out-of-the-box IDE. The most important aspect of all is that you reason differently about writting and editing text, in a much more efficient way than normal.

But by no means do I judge people for not doing it, as I said in my initial comment, everyone has their needs. Vim turned out to give me great power and comfort after all and I can barely go back to another editor. Maybe it's not the same for you. All is fine.


I got pretty good with vim. I'd say it was the fastest I could ever edit text. It really can be insanely fast for editing text but ultimately, I don't like vim. I don't spend that much time literally editing text, like a copy editor. I spend much more time typing and thinking, and very little editing.

I can touch type both QWERTY and Dvorak. I usually type Dvorak, and the longer I type QWERTY, the more I get this mental fatigue of continually overriding what my fingers wanted to do. Using vim gives me a tinge of that feeling, that I wouldn't recognize as a hint of that feeling if I didn't know how the bigger version of the feeling feels after a day of typing QWERTY. It has something to do with the impedance mismatch of hitting keys in the wrong mode/forgetting what mode you're in (humans are terrible at moded interfaces) and throwing around a minilanguage for text editing in my head besides the actual task I need to do.

Saving 2 or 3 minutes of text editing a day isn't worth the aggravation.

I would say you can feel like you have a godlike sense of power over the text, like you're playing Age of Empires. Some people probably like that, and equate it with productivity and time-savings. It's optimizing for the wrong thing.


It worked out the opposite way for me. Using vim bindings keeps me in flow. If I don't have them I get aggravated, every time I have to slog through an inconvenient editing task because I changed my mind about some bit of code. It's not the seconds I save that makes me more productive, it's the mental state it helps me stay in.

It doesn't resonate with everybody, but I think it's going too far to say it's optimizing for the wrong thing.


A lot of us are fans of the keybindings more than Vim itself. For a long time my main editor was Visual Studio with Viemu.


> It continues to surprise me why people have such strong opinions about someone else's editor choice.

I think because people identify themselves too much with their editor, programming language or whatever else choice. Everyone wants to think of themselves as the smart ones, only making objective rational choices, so everyone else making other choices has to be stupid. If now someone criticises their choice or argues about other choices, then they feel personally attacked, and there the flamewars goes.


An alternative take, definitely worth a read: https://www.gwern.net/Holy-wars


There is a very rational and not emotion-driven incentive to spread your subjective preferences.

For vim: plug-in development effort. Nowadays we have to recycle VSCode ones because Vim is seen as too niche to develop for it directly.

For vegan: meal availability in shop and restaurants.

For Android vs iOS: app availability.

https://www.goodreads.com/book/show/28820444-the-elephant-in...

(edit: I'm basically paraphrasing eindiran's argument)


Vi also benefits a ton from being installed pretty much everywhere. If you use the default vi keybinds you rarely have to rethink your muscle memory for actions.


Yeah, I guess that is it. The existence of the vegan is a moral judgement of everyone else's food choices, so they get hate. The existence of the vim user reminds you of that one time you gave it a shot and it didn't stick, so it makes you feel attacked the same way.


I want to say one thing in defence of vegans, you only know about the vegans who tell you they are vegans. These people are actually the people-who-like-to-tell-you-they-are-vegans.

There a lot of vegans who don't eat animal products and just leave it at that. Like my partner who just cooked me an anchovy pizza.

You never hear about the just-a-vegan-and-god-knows-why-you'd-want-to-tell-everyone, because they creep through the world, in absolute dread of being discovered by the like-to-tell-people-they-are-a-vegan people.


But anchovy is a fish ... how is that not eating animals?


I had to stop and think about that, too :)

I think what the poster meant was "My partner is a vegan (implication: they would never eat anchovies), but they just made me an anchovy pizza so that I can eat my non-vegan food happily." I.e., their partner doesn't eat animal products but the partner isn't judging their choice to eat animal products.


You missed the point. The partner who made the pizza didn’t eat it.


My current theory is vim users are like vegans/gluten free/paleo/etc, in that its a personal choice that some are public about, and people love to hate on it and "disprove" it for the same reason.

I think there's some truth to that.

I've been vegan for 20 years and a Vim user for half of that time.

Back in the day, I was questioned a lot about why I was vegan, being asked all the time where do you get your protein? Grateful those days are over.

Vegans can tell you the worse people are the former vegans, who almost always had a bad experience of some kind being vegan and want to tell anyone who will listen.

I think people who tried and didn't get Vim are often the ones wanting to disprove that Vim is any good. Because obviously if it didn't work for them, it can't be any good.

The subtitle for Drew Neil’s Practical Vim book is Edit text at the speed of thought and that's kinda how it is when you start to get pretty good at Vim.


> The "suffering" has honestly been overblown by jokes about not being able to quit on one side and the mythologizing of the leet ninja 10x programmer who is only bound by his typing speed and can't waste time reaching for the mouse, on the other side.

I don’t think it’s all overblown. With a GUI editor if you’re not efficient with it you can fall back to using a mouse until you know enough shortcuts. With vim if you don’t know enough of the controls for even basic navigation you can’t do much, the learning curve will always be steeper, and some people don’t want to go through that even if it pays off in the end.


people have such strong opinions about someone else's editor choice.

I want to reiterate that I'm merely pursuing an intellectually curious line of inquiry into whether modal editing enthusiasts are brainworm-infested cultists, not engaging in base mudwrestling about editors, which the guidelines forbid.


I want to reiterate that I'm merely pursuing an intellectually curious line of inquiry into whether modal editing enthusiasts are brainworm-infested cultists, not engaging in base mudwrestling about editors, which the guidelines forbid.

Absolutely.

I am not wedded to my editor, I happen to prefer Emacs, if it’s not installed I shrug and use cat and sed. The older more experienced people at my company tend to use vi or Emacs. The younger ones use VS Code, PyCharm, Sublime etc. And they spend an awful lot of time on chat asking “how do I do this simple thing in my editor??” that you simply don’t see from the Emacs/vi crowd.


This is personal experience of course but I have not seen that to be the case in my company, irrespective of editors people have mostly the same type of questions. Out of curiosity, what kind of questions do the non Vim/Emacs folks keep asking?


Out of curiosity, what kind of questions do the non Vim/Emacs folks keep asking?

The most frequent questions are things like "how do I edit files remotely" or "how do I make it work with Git" or "how do I make this function a keyboard shortcut" and so on. Basic stuff. The rest is about which of a dozen competing plugins is better for something.

They can't help each other because they are all using something different, but they would be incredibly indignant like their human rights had been infringed if they were ordered to use a company standard editor.


> it's mostly about accepting the (evidence-free) premise that modal editing is actually a good thing.

Kakoune's development has started fairly recently. The oldest tags on its GitHub repo are for 2018. I think this defies "people want to continue the legacy of actually-not-that-great thing because I had do suffer, so other people should too". I think you'd only put into making/promoting Kakoune if you genuinely thought modal editing is a good thing.

Whereas, if the bigger value in "I learned modal editing" is the signal of "modal editing is hard, so anyone who knows it must be good" (rather than value from a better developer experience), I think aiming to make modal editing more intuitive/accessible is counter-productive.


The difference between a modal editor and a GUI one is that in the GUI one, the commands are organized in the menu and you access this mode(the menu display mode) by clicking instead of pressing a key.

In fact, if you use shorcuts, they are the same thing.

Modal editing is not hard. I learned vim and emacs without problems. Step by step, focusing on what was the next thing useful for me and learning it after that.

Not harder than learning German or English or Chinese Mandarin. Any human languages is way more sophisticated and people learn it anyway.

There is 3.000 words (or commands) that you need to use to speak a basic language. 20.000 if you are an educated person.

Do you believe that if people in Germany speak german fluently they are trying to signal anything to others?

People learn a language because they use it. As simple as that. The more you use it, the easier it gets.


If the commands are well organized in the menu, any fool can find them. But remembering dozens of shortcuts clearly signals you know more than those who do not remember them. How would people recognize true experts if we all switched to less arcane versions of Notepad?


> Modal editing is not hard. ... Not harder than learning German or English or Chinese Mandarin.

Oh sure, it's not hard at all when compared to something really hard!

> Do you believe that if people in Germany speak german fluently they are trying to signal anything to others?

No they speak German because that's the easiest option for communicating with other people. Vim is not the easiest option for text editing.

Terrible analogy.


>Oh sure, it's not hard at all when compared to something really hard!

I guess the point is that it's not as hard as many people make it seem. I switched from Sublime Text to vim and in a matter of one or two days I felt comfortable editing text with it and in contrast to other editors the learning curve quickly flattened, because you're actually learning a rather simplistic language with grammar and a small vocabulary, instead of memorizing key sequences which most of the time don't follow any logic.

> No they speak German because that's the easiest option for communicating with other people. Vim is not the easiest option for text editing.

What is the easiest option then? And I'm not talking about the easiest option during the first week, but afterwards (i.e. the majority of time).


> What is the easiest option then?

A non-modal editor like VSCode.


Oh once you've suffered, there's a huge, inexorable incentive to believe you haven't suffered in vain! Completely agree with you that the belief is genuine and sincere. I just don't happen to think it has much basis beyond its authenticity and sincerity.


You simply don't understand.

Do you suffer for thinking on English? Do you suffer for driving your car and changing gears? Do you suffer for using a pen for writing?

You can try to write with the hand you don't usually write with. You would suffer if you try to write the same things you write with the other hand but if you improve a little every day over time you will be capable of writing with it well.


I think there’s been a conflation in this thread between suffering and struggle. It’s possible to have one without the other. Struggle is a requirement for learning very useful things.

It’s entirely possible to learn modal editing without suffering but it’s not likely to learn it without struggling, given how most people are raised on the mouse.


My own contrarian and probably equally wrong take is that it's mostly about accepting the (evidence-free) premise that modal editing is actually a good thing.

Yes, equally wrong. ;-)

We deal with modes all of the time—when you're backing up your car, the car is in reverse mode. Microwave ovens have modes depending on what you want to cook. I use the popcorn mode on mine a lot. Anyone who've ever used a VCR knows what modes are.

So having an editor with modes shouldn't be a foreign concept.

But it's not just about having modes; it's how well thought out Vim is. Even though I've been using Vim for about 10 years (after trying many other editors and getting frustrated for one reason or another), I keep learning more useful things.

I recently needed to edit lots of messy Markdown files for a friend. I knew macros existed but I never bothered to use them. Before I knew it, I was using a couple of macros that really cut down on the tedious work I had to do.

Same thing with regular expressions—I knew about them but I had never gotten around to learning them. Combined with Vim’s composability, regular expressions gives you super powers.

The other thing about Vim I've always appreciated—it's been around so long, articles and videos from 10 years ago are still relevant today.

For example, back in the day, I used to watch Derek Wyatt’s Vim tutorials.

Rewatching some of them today encouraged me to learn macros and regular expressions. When I recently watched this one (https://vimeo.com/15443936), where he extracts plain text out of a messy looking XML file using regular expressions, I was like I want some of that.

Any software made for people who take their tasks seriously—GUI or command line—is going to have a learning curve—I think it's exaggerated for Vim. But the payoff is well worth it.

I just installed Big Sur on my Mac. Everything went smoothly for me, but not everyone was so lucky. Even if I had other compatibility issues, Vim just works. As long as I have a terminal, Vim and web browser, I can be productive.


I don't think your take is wrong. I have yet to see any actual argument from the vim/emacs crowd. I'm genuinely curious about what makes them defend their editor choice that heavily but whenever I ask them for their reasons all I get is a "modal editing is great because modal editing is great".

I can somewhat understand "don't have to touch the mouse" as that's a personal preference for them (even though IDEs have key binds too, I think they blow up that argument way too much) but on anything else they are suspiciously silent. Maybe I have just not met the right people to ask but that's my personal experience. Anyone I know using vim only does it because they either have been using it for 40 years or have been told to use it by someone from the first group and don't know anything else.


It does all come down to personal preference in the end. I can only describe why I prefer Vim. I specifically do not recommend it to anybody else - it's hard enough to learn that you have to decide on your own that you want to make the effort.

In my opinion, the real drag of conventional text editing is constantly having to move between the keyboard and mouse. That's a much more physically and mentally expensive mode switch than any editor mode switch. It always tends to hurt my focus on whatever I'm working on. Vim feels like I have all of the movement types in muscle memory, and it just seems to happen automatically.

I know all editors have keyboard shortcuts. I think they're all much more awkward and inefficient than Vim though. Too many steps and too much thought for "how do I move the cursor over there without using the mouse". When it gets beyond the basics, the keyboard shortcuts either don't exist at all, or vary widely between editors. How do I split a view into 2 sections and switch between them with only the keyboard in VS Code? Beats me. Oh it may be possible, but if so, it's probably different in IDEA, Eclipse, full VS, Sublime Text, etc. Vim is always Vim.

I also find most of the IDE features for live error checking and auto-complete to be more distracting than helpful, at least for dynamic languages. It's subtly annoying and harmful to my focus for my editor to be constantly trying to tell me about the "syntax errors" in code I'm not finished writing yet, or to constantly pop up completely wrong autocomplete suggestions. I prefer to run these checks or unit tests explicitly on command, when I'm ready for it.


Here's my story: I used Notepad++ for a while, Sublime Text 2 for a couple of years, Atom for a bit, then Webstorm and VS Code before settling into primarily using VIM or VIM mode for every editor I work with.

The real instigating factor was severe RSI. Three and a half years ago, it hurt even to brush my teeth. The damage was primarily from using trackpads, mice and worst of all mobile phones, but it was much to late to just use a keyboard.

I had to take a complete break and then limit myself to a couple hours a day and only on a fully ergonomic mechanical keyboard. The difference in using VIM and staying mostly on the home rows vs constantly hitting chords with modifier keys to do everything on other editors was massive. I could work almost twice as long before feeling pain!

At the time I could get around VIM but hadn't ever customized my .vimrc or really made a concerted effort to study it. I just knew the standard navigation with hjkl, insert, append, copy, yank, delete, lines, words and find. And yet it was still reasonably productive.

Once I learned about change/delete/yank in word/tag/line/etc, it was already better than using VS Code in normal mode. Making shortcuts in my .vimrc made it even better. In a sense it's like snippets at a meta level that apply to your work flow.

Nobody pushed me to use VIM and I like it quite a bit, despite having had a lot more experience with non-modal editors. I'll use VS Code, etc, but I when I do, I use VIM mode in them unless I'm recording a screencast where I don't think that would be a good idea. So far, the only major editor I've encountered that fails to support VIM mode is Xcode.


Damn sorry, I hope it gets better for you. In that case I can definitely see how not having to leave the keyboard is of upmost importance.


Thanks. It is slowly getting better. My wrists and right index finger still hurt after using the computer but much less than before and I'm using voice input a lot less these days.

Sites that require a lot of clicking are still painful, though.


I was a short-term vim user, around 8 years. There are some benefits to it, however these benefits are starting to get less and less with other IDEs/Editors adopting some of the functionality. I now use VS Code with vim keys.

So as from my point of view of would highlight the following reasons:

- Keyboard, for even a bad typer like myself the vim keys and chords are very efficient.

- The not using a mouse is good also, your hands do not move far. - Fast

- Widely available

- Cross platform

- I can use it in a SSH session.

- When you use it for a while you do build an attachment to it. It might sound strange but I feel good using vim.

I think my vim experience has one major benefit also. I have been able to jump from one ide/editor to another and if there is support for vim keys then I can navigate and do basic to mid level editing quite efficiently.

I like VS Code now, it is consistent, plugins work consistently (one problem with Vim). I would still recommend people to learn vim.


I'll name one use case where Vim's approach helps me out a lot: macros.

Quite often I need to edit a whole bunch of lines of code/data in a similar way. simply being able to repeat a particular set of 'motions' x times, or on whatever line I'm one, has often proven quite useful.

I'm sure that many people don't really need to do this much, but for me it's probably something that crops up daily (when I'm working), at least once. Often multiple times.

The fact that I can perform complex operations and record them with no extra mental load, is definitely one reason I'm sticking with Vim (or rather, evil on Emacs).


That's a reason I can get behind. I agree though, most people probably don't need that, but in such cases it's great to have a tool like that available. Thanks!


I'd say that does illustrate why I chose to just get proficient in Vim though. There are enough of these kinds of scenarios where having it available is very useful. But if you don't know Vim, you wouldn't bother learning it for just them.

For example, I couldn't imagine using a browser without Vim keybindings anymore. I wouldn't have learned how to use any kind of shortcut/keyboard-only extension, but since I already used Vim it was a no-brainer.

It's a lot of little benefits here and there, and I think taking a bit of time to get comfortable with it would even benefit no-programmers who do a lot of text editing. Plus geek cred ;).


Me and my friends learned with Vim first (not really a choice, our exams were basically on fresh installs). One of us got into SublimText quite fast (with modal editing too, using vintage), while another went into vim scripting and python, and another with neovim.

It was our first year, i don't think we even finished our Posix shell project at that time, so our knowledge of vim's binding was very limited, as we spent less than 6 month on it. But this was really comfortable, and even the two people of our group that learnt to code prior with the Java IDE got hooked with modal editing, vim or not. Because once you've learned how to use it, it is just more comfortable. I still know how to use ctrE and ctrlA and basic shortcuts present with every IDEs, but the `find ", move one right, delete all util next "` i don't, and i'm pretty sure is not the same on Atom or Netbeans, and since i've already learned the superior `ri"` (replace inside ""), i don't understand why i should learn more complex shortcuts.

I mean, even `delete from this word until the end of the line` i'm pretty sure won't be the same within two editor (you'll have to find the word with control f, place a mark wich differ depending on the editor, CtrlE, then either place a second mark or delete from the first mark? i guess?). I like consistency and not having to place mark and think on "how will i do that".

I'm not saying modal editing is better, i think it's just like learning to use a new tool. Let's say you want to add floorboard in your house. You know how to use a circular saw (everyone does), so you use that, and that's okay and probably enough. I've learned how to safely and correctly use a radial saw however, and will rather use one if i have the choice. It's not better inherently, i'm just lazy and i find using a radil more comfortable (as long as i have earplugs available).


I think editor choice is pretty subjective, but for me it's two main things:

1) Editing speed. I'm far from a Vim power user, but anytime I have to use a different editor, I'm frustrated by how slow and cumbersome it is to edit code. It feels like trying to run in water.

2) Ubiquity. It's so nice to just use the same editor everywhere, especially remotely and/or on low-powered devices.

On point #1: This is not just an issue of familiarity either; I've used way too many editors over the years, vim wasn't my first choice, and I resisted it for a long time. Once I bit the bullet (due to point #2, above), I found that the learning curve was really steep as expected. But an interesting thing happened soon after that: long before I felt proficient in Vim, the speed of editing files in Vim surpassed the speed of making the same changes in any other editor.


For me, modal editing is great because it's comfortable. I almost never need chords save for those using control, which resides in its rightful place below the tab key.

Lots of typing, zero RSI.

Modality also enables the vi "mini-language" that makes editing actions and movement composable, which is nice.


I am an avid (Neo)vim user. I love it and have been using it for the last 4-ish years. I know it's not a lot, but I _am_ in my early 20's. :D

I started coding only during my undergrad (computer engineer), so first editor/IDE was Eclipse, and then moved to Atom -> Sublime -> CLion. By the time I reached my 3rd year, I was writing C/C++, and took this course on Operating Systems. The course taught on the OS/161 teaching OS [1], which (at the time) used BSD Make and other magic, and I had no idea how to configure my CLion IDE to handle it. The course professor was a Vim evangelist, and actually dedicated a weekend to teach Vim for anyone who wanted to learn. Since, then I have been hooked. (Point being: I haven't existed for 40 years, let alone used Vim for that long, nor have I just been told. I think there is some comment in this post that compares learning Emacs/Vim to learning foreign languages, which I definitely relate to.)

Why I like Vim:

1. I can separate my text typing with text manipulation (if that makes any sense). 2. Cliche, but I love that I don't have to use my mouse. I don't necessarily care about the speed of it (I have RSI from using my keyboard too much, so I am actively slow) but having to switch to a mouse and then search for the button I want to click, etc. is a significant mental strain/distraction for me. 3. Command mode is not the same as keybindings in IDEs: I have used several IDEs (outside the ones I mentioned above) and I always found keybindings to not be intuitive and also involves having to press a bunch of unrelated keys. I think the reason why Sublime/Atom/VSCode have a Command Pallette is exactly for this reason, and IMHO, Vim does it better. 4. And, finally, the most important reason: I don't have to leave the terminal. I have a setup that uses Neovim and Tmux, through various high-quality plugins written by some really awesome people. It is seamless. I have latex compiling in the background, I can edit command line arguments to Clang without having to hop through multiple dialog boxes, and so on.

[1]: http://os161.eecs.harvard.edu/

Edit: Forgot to put link to OS/161

Edit: Found out that the original website for the course I took is still up at https://ops-class.org/courses/buffalo/CSE421_Spring2017/


- I learned vim/emacs on my own in my second year of undergrad. Because I am the kind of person who wastes time searching for the best tool for the job.

- I have since tried to make more people use them, and pushed them as a TA of the advanced programming class. Nobody likes these stuff. They are useless for most people. The only real usecase is for sysadmins who need to quickly edit files remotely.

- Even if they were somehow some gatekeeped holy grail that only rich people with mentors got; So what? If rich people with a lot of resources (including mentoring resources) can’t do better than us normal folks, then doesn’t that mean sth is fundamentally broken? More resources should translate to more knowledge/skills. The fact that in our current world the conversion rate is so inefficient (especially since these rich folk probably enjoy mildly better genes as well) is evidence that our current education methods do not scale. A corollary of which is that the US should spend a lot less on education which in the end doesn’t produce any results. (Compare the US expenditures with other countries.)


> but many of us hardcore Vi/Emacs users have had this knowledge imparted to us from a mentor. Thats probably why the use of Vi/Emacs is much higher in established tech environments (universities, big dotcoms), where there tends to be a tradition of mentorship than it is elsewhere

My mentor was vimtutor.

Seriously, learning basic vim takes 30 to 60 minutes with vimtutor.


My mentor was a humble man from the Turkish countryside. He held dual masters in EE and CompEng. He knew vi because what else would he possibly know? It's what he learned in university. And, so, he taught me what he knew. I've mentored about 2 dozen people and I've taught them all vi(m). As far as I know, though, it's only stuck with 2 or 3 of them. C'est la vie.


vim as initiation ceremony - a near-death experience where the initiate is reborn as a member of an arcane sorcery guild.


I work at a trading company on builds and developer productivity. vi is known by all 600+ people that touch code or admin systems as a baseline. I think we mention the basics in our dev school. If you need to edit somewhere outside your personal host, your choices are basically ed/vi. IntelliJ dominates Java development at well over 90%. CLion is what we teach for C++, but it's roughly 50% CLion, 30% vim, 10% Emacs, and 10% other (vscode mostly, but I've seen basically everything). I'm not sure of our Python breakdown, but I suspect IPython Notebooks/Jupyter dominates everything. For random edits, I see about 50% vi, 40% vscode/sublime, 10% emacs.


On Windows, use Bitvise. SSH into your Linux box. Use the file browser GUI to navigate to your file. Edit it in Sublime, or your favorite editor.

Vi is ok for viewing files on a terminal, and for small edits, but it’s rather mediocre for any significant amount of development work.


> Vi is ok for viewing files on a terminal, and for small edits, but it’s rather mediocre for any significant amount of development work.

May I ask what prove this?


One of the statements I see a lot is that mouseless, keyboard only HCI is faster. But as far as I know, to the extent that any real studies have been done at all, this assertion is false.

I don't have the references at hand but I think people like Alan Kay and designers at Apple would think it crazy to even suggest that a keyboard only HCI is more efficient.


Could You please add a single example for faster solutions to modify several (text/source) files' contents at once with mouse and/or touchpad mainly (or any other already existing HCI interface)?


Who said anything about a mouse and or touchpad mainly? As far as I know, the studies were for keyboard and mouse in combination and actually predated touchpads.


Interesting take. I came from a CS background but our school was mostly in emacs land on the surface (e.g. newcomer CLI tutorials included it as an upgrade from nano, and nothing on vi)

What brought vi to our attention was the holy war itself, and the sheer appeal to decide which camp we fit in.

50 years ago I think it’s a completely different story, but from the point BBS and shitposting were a thing, we got most information we needed on the net, including editor wars, linux distribution elitism, PHP and javascript and so many things.

It can be a kind of indirect mentorship, but I think even today a lot of people go try vim for the memes (and stay or not for the efficiency)


Can confirm. "Can't exit vim" memes were what introduced me to vim. Though as a primarily windows user, I don't use it much.


Try Mobaxterm on windows, it give you vim, grep, awk, xwindows and Linux Land tools in a nice single installation.

Current versions of windows can do scp, ssh, rsync out of the box in the windows console, but I believe that is less then a year old and many people don't realize it.


I got into Linux from a networking background. Windows just didn't have the same network tools available, and they were all expensive. At the time I was mostly doing non-profit sysadmin work.

It took me about 5 years to transition from nano/pico to vi/vim. I'm still learning, but I recently loaded Debian on a VPS I use and was surprised when visudo defaulted to nano. It seems so much less powerful and actually more difficult to use.


This probably common, but there's also people like me, who stumble upon a problem like having to edit text files via ssh and end up falling in love with it. I came to vim that way some 15 years ago and to emacs (evil mode) two years ago. Both are simply awesome, powerful programs that are not hyped often, but by learning them you hopefully learn something to use for decades to come.


Same, I have never seen anyone else IRL using vi[m]. It mostly started for me due to my potato machine and I like to live in the terminal.

But I have not switched to emacs(evil mode ofc.) due to mostly philosophical differences and i completely just hate the defaults..


Then I have one counter point of anecdata for you:

I knew no one that was openly proficient in Vim when I picked it up. In my studies, I was already one of the two to three odd-one-outs who used Linux (>90% of students and professors didn't know anything besides Windows).

I bought an ARM-based chromebook, installed crouton and... quickly discovered, that nothing besides Vim/Emacs came pre-built for it. There even wasn't a simple, official way to build Electron (so all those editors weren't an option, either)!

So you could say, I only picked them up (I tried both) reluctantly. And I stuck to Vim-bindings because all other alternatives I know suck in comparison. The best I knew beforehand w.r.t flexibility was Sublime Text with its multiple cursors and regex searches, but that also pales when compared to Vim macros.

Make of that what you will. I'm certain your point about mentors isn't wrong, but it doesn't explain it all, too.

Also, if anyone could point me to similarly promising editing schemes, I'd be glad to have a look at them :)


Yup. I use vim because a senior team lead used it and it was the unspoken defacto editor to use and as a (very, very junior) dev at the time it was engrained in my psyche.

Stockholm syndrome aside I use it still because of all the inertia of learning I put in. I’m getting ever more productive with it so I’m sticking with it.


https://kakoune.org/ is a vim variation which I think would be much better pedagogically. More predictable, and much more help and feedback as you edit.


i think the gatekeeping involved is more personality type. learning vim/emacs is kind of like learning to play minecraft. you either have to really want to, or on the receiving end of peer pressure. as an emacs user who’s never gotten into vim, I definitely am going to try this ‘vim tutor’ someday when I have some time to kill.


Actually the gatekeeper is what they call themselves as "mentor", not the tool users.


IME almost everyone who's "self taught" started with some kind of mentor.


More so than even the choice of editor itself, I think the biggest argument for vim or emacs, especially for students, is that you “live in” the *nix cli.

The amount of stuff you soak up being a unix tool user is just night and day compared to using sublime text or something. Because using a cli text editor implicitly sets you on this path of learning through the command line. So you start with cding and lsing around, opening your file in vim, typing gcc or whatever. In a very frictionless and natural way, pretty soon you’re reading man pages, writing shell scripts and makefiles, etc.

In a very real way, the Unix command line environment has you poke around an interactive “boiler room” of your computer, and that type of learning, learning by exploration, is something far different from learning individual tools at a higher level of abstraction.

It’s like letting a kid loose into a master’s workshop instead of showing them one tool at a time. By seeing everything “together” and exploring what the different tools do, the “fog of war” of unknown unknowns clears much faster for a novice, and this provides a MUCH more solid knowledge footing to build on.


What most people forget when they argue against learning vim is that vim is more that just a text editor, it's a whole new philosophy. Once you learn it, you can find it almost everywhere. Learning vim key-bindings was the first thing I did after learning to touch-type, and now I use the same key-bindings on VSCode, Intellij, a remote server I am SSHed into and with the help of Vimimum, even chrome!

And if ubiquity isn't enough, then I would point you to this article which does an awesome job explaining the really idea of vim, composability.

https://medium.com/@mkozlows/why-atom-cant-replace-vim-43385...


Unfortunately, vim macros don't tend to get implemented when other editors implement keybindings.

This is unfortunate, vim macros are fantastic for reformatting text.


Maybe not all of them, but you can use macros in IntelliJ and VSCode implementations (and, of course, Emacs).


Exactly this. Vim is special because it's what we've all agreed on as a standard for modal editing. Luckily, it's also pretty darn good, but that's secondary. Learning one set of commands that can then be used across editors, operating systems, and even terminals is amazing.


> Vim is special because it's what we've all agreed on as a standard for modal editing.

Well I didn't vote for you...

In all seriousness, Vim's keybinds are only popular because no one has really tried to make a good modal editor with different bindings. It's prohibitively difficult to change the bindings in Vim, and prohibitively difficult to change muscle memory, but I still wish that I had a good modal editor that didn't resemble Vi.

It's a similar story with keyboards and qwerty.


chrome? how?


> with the help of Vimimum, even chrome!

Even though OP made a typo, he more likely wanted to say Vimium.


Also "Vim vixen" for Firefox.


Here's why I taught vim to students (at a coding bootcamp, in 2017).

- vimtutor does all the work for you.

- Like the author says starting up and editing with vim "just works".

When I "teach" vim, what I'm really doing is grading their homework. After their vimtutor hour, no student asked me how to edit git commits.

I know it might seem lazy (it is), but when there's a teacher better than you, don't teach it yourself, delegate. I happily delegate to vimtutor. Miss or mister vimtutor, you're a better teacher at vim than I will ever be.


I learned to use vi because it was the only full screen editor available in the Unix machines I was using in 1983. At that time, I occasionally still used ed for simple edits because I didn't want to wait for vi to startup :)


I'm a Vi/Vim user since 2000, when I started transitioning from my ISP junior tech support job into a corporate support/sysadmin job. Vi was what everyone used, so that's what I was taught. I was just shown the basic 5-10 key commands, then I was on my own. Life got a whole lot easier when I invested about $15 in a Vi cheat sheet coffee mug. Never looked back.


Link to the cheat sheet and coffee mug?


Here it is [1].

I just found it in the back of my crockery cabinet! Looks like it's stayed in amongst my possessions for the nearly 20 years since I got it, through several house moves and stints in storage. It's going back on my desk now.

I can't find any the same as this when searching for it online now, but this seems the closest [2].

I like the simple text design much more than the coloured keyboard layout [3]; much more in keeping with the vi ethos.

[1] https://www.dropbox.com/sh/ngj8wt96ld1di0q/AABcpi8fuQ9hUkIP-...

[2] https://www.cafepress.com/mf/10388170/vi-reference_mugs?prod...

[3] https://www.zazzle.com.au/vim_cheat_sheet_coffee_mug-1686145...


BTW I've just remembered that the mentor who introduced me to Vi was also the person who told me I should switch from AltaVista to Google. Heady days.


Googling for “vim coffee mug” provides reasonable hits.


The second hit includes a CafePress mug where the keyboard navigation diagram is wrong. So maybe they’re not all equal.

https://www.cafepress.com/mf/54286678/hjkl-vim-navigation_mu...


Yeah, it might even return many similar products of varying quality, which is likely why the person you're replying to is asking which particular one they found useful.


Why I started to use Vim 5 years ago. I was coding a lot and I realised most of my work was editing code as text. So I figured, why not become really freaking good at it? Vim has a steep learning curve because it's a mental paradigm shift. I personally would recommend it to everyone because although no-code is taking off, most of the developers are still editing text. Sharpen that saw!


> no-code is taking off

I don't see any evidence for that.


There are many aspects underlying digital transformations that large enterprises are undergoing...among the many, is to empower more "citizen developers" with tools that are lower-code and no-code. (I'm not convinced that no-code is a great thing just yet...but not because of the tools, rather the mindset...so we'll see how the next generation adopt these no-code tools...or not). Within these transformations, the premise of "no code" is becoming bigger and more popular...so if you're not seeing it yet, you will soon enough more and more. Not that my following note is a large representation, but when i was applying for a new job during latter 2019/early 2020, over 90% of the jobs that i applied to made mention of some sort of "digital transformation", and no-code/low-code goes part and parcel with those types of efforts. Again, low volume of data, and biased towards mid- and large-sized enterprises...but, it is a thing for sure.


You shouldn't be editing "text" but "code" however. Text editing is low productivity task whereas code editing should happen mostly be at much higher level.


I really wish there was a batteries included vim-like console editor with all the power of the jet brains suite of IDEs and convenience and lightness of vim.

As it stands right now I end up using both an IDE and vim.

Maybe emacs is the answer but honestly if I look past all the yak-shaving to get emacs to the power level of an IDE does it really get to the point where it has everything that say CLion has?


I'm not sure about the specifics, but providing something a lot more "batteries-included" seems to be the idea behind Emacs distributions like Spacemacs and Doom Emacs.

One difficulty is that language-specific tools (language servers, linters... etc) are standalone pieces of software with their own dependencies, requirements... etc. It's hard to bundle together a fully "batteries-included" Emacs without figuring out a way to manage native software and services.

I think this is one place where Nix can be a real advantage: even if you don't care about Nix's reproducibility, it's ability to manage Emacs, Emacs packages and language-specific tools is pretty unparalleled. If I had some more time on my hands, I would try putting together a Nix-based Emacs "distribution" with some easy way to configure which languages you want to work with. Coupled with lsp-mode and language-servers, this has some real potential!


I'm positive some sadist somewhere in this world has all the software on their OS as a nix expression. I'm also positive that at least one of these people has a fully featured emacs IDE and all the required dependencies as part of that expression.

Totally down to try it if anyone has it.

One thing good about just standalone vim though is how portable it is. I can ssh into any server and fire it up. I also want this for a IDE. I want a console level IDE to fire up on any server I ssh into and if it's not in that server I want to be able to use any package manager to DL it easily.

I can't see any editor/IDE solve the above problem unless the editor becomes the ssh client itself. With that setup in place then my IDE can go anywhere.


"the editor becomes the ssh client itself" is effectively how I use Emacs. TRAMP (https://www.emacswiki.org/emacs/TrampMode) makes editing remote files pretty much as seamless as editing local ones. I even semi frequently do slightly-crazy-seeming things like open files via chains of several ssh hops and I can "save" them (read: marshal a complex operation involving scp, base64, and other sourcery) in exactly the same way I can save something to the home directory on my workstation. TRAMP is a default part of the Emacs distribution (and has been for over 10 years), so it doesn't require installing extra packages or even enabling anything. It's just on by default.

This capability, plus "frame" management commands and the various terminal modes make my use of Emacs roughly equivalent to they way I see colleagues (I'm an ops/sysadmin type, not really a developer) using vim + tmux.


Oh yeah, I am one of those people myself[1] :). But my setup is quirky and hard to customize. (Well, hard to customize for other people, anyway.)

Nix had a learning curve, but once I got over the initial hump, I stopped wanting to manage software any other way.

To get from my setup to what I'm thinking of here, I'd need to organize it as a package that's convenient for others to depend on, fill in a bunch of missing systems and factor out support for specific languages and tools into some kind of module-style config system. Thinking about it now, it's probably just a few days' worth of work.

Emacs, by the way, does work as an SSH client (via TRAMP). I do all my work on remote servers by SSHing from a local Emacs. It's not perfect, but it works well enough in practice that I haven't tried finding anything better.

[1]: https://github.com/tikhonjelvis/dotfiles


funnily enough it's something I've been working on for my personal dotfile setup but instead unfortunately decided to go with ansible for now despite being a big fan of both nix and nixos. Nix was just a bit too heavy for some of the small lxc containers etc I wanted to setup.


you could consider sshfs


This actually exists for Common Lisp: https://common-lisp.net/project/lispbox/

It would probably be doable for other languages, if you were so inclined


Emacs mostly has problems with external language servers because its plugin model is archaic and brittle to a large extent compared to that of say VS Code. It's also far more flexible but with power comes responsibility, and I've found Emacs extensions far more likely to interfere with each other than in less composable editors. You don't need Nix to fix this problem.


Nix would help pull in the right versions of all the external non-Emacs packages you would need for a real IDE experience. Almost all the issues I've had with Emacs plugins have boiled down to poor interactions between Emacs and external software (wrong versions, wrong paths... etc), and Nix could fix basically all of it.

As a bonus, using Nix to manage Emacs dependencies would also give me full control over exactly which version of each package to pull in. This would create much more of a "distro" experience without needing any extra infrastructure.


Given the brittleness there should be at least a single configuration that works. I believe that tikhonj is right in the sense that nix can capture this configuration. Nix is not required but I can see how it can help.


Nix would be useful for a description of the non-Emacs dependencies. Particular versions of the compiler and LSP program. -- Some languages are more fickle about this than others.


This was indeed the promise of spacemacs. I tried it a few times and roughly 30% of the advertised features were broken out of the box.


I've used Spacemacs for Clojure development for many years without issue though it looks like it isn't being maintained much now.


Micro editor is a pretty good balance of lightness and batteries included.

https://micro-editor.github.io/

HN discussion: https://news.ycombinator.com/item?id=23334190


Emacs is not an IDE, it’s a multipurpose tool with many of the same features commonly associated with IDEs. Spacemacs and Doom Emacs (my recommendation) are highly useful distributions that make a lot easier to achieve that goal.

But, even so, Emacs will still not be an actual IDE like those made by JetBrains.

You sacrifice some specificity for a world of flexibility.

An IDE-like Vim would be a negation of everything that Vim stands for. I don’t see any point in that.

If you really need an IDE, just use one.


>Emacs is not an IDE

No it's not. Why are you telling me something I never said? I believe you are utterly mistaken to believe that I hold this opinion.

>If you really need an IDE, just use one. >I don’t see any point in that.

You don't see the point because you completely missed the point.

I want an IDE that is as lightweight as vim/emacs and as powerful as a Jetbrains IDE and lives on the console.

So right now if I "just use" an IDE it's not lightweight as it likely runs on the JVM, I can't fire it up on a console when I'm ssh-ed into a server.

If I fire vim up on a server I can't get any code highlighting or code following or integrated graphical debugging without a lot of yak-shaving and even after I do the yak-shaving it's still not done as well.

I want both on one app. Now you may not like this idea, you may be opposed to it. But this is what I'm asking for and this is my opinion. I respect your opinion but please don't tell me to "just use" an IDE when that is not the topic of the conversation.


> No it's not. Why are you telling me something I never said? I believe you are utterly mistaken to believe that I hold this opinion.

For clarity maybe? Relax dude. You are not on trial.


>Relax dude. You are not on trial.

Uh. I am relaxed. I'm trying to get you to relax. You should be more self aware as you're actually the one that kind of seems on edge with your initial post.

You barge into this thread with a tone that is dismissive, opinionated and wrong. You're telling me to "just use an IDE" and also that "emacs is not an IDE." I'm just telling you to stop doing that.

I usually won't tell someone to "relax" or that they're "not on trial" because it's kind of insulting and dismissive. It's also a strategic move used to flip the script to make another party seem overly emotional.

Just Read the thread next time before you respond so aggressively with your opinionated views.

>For clarity maybe?

Nah not for clarity, this is a lie. People aren't stupid and they know why they say the things they say.

You said it because you believed that I held that opinion and you wanted to dominate the conversation by telling I'm wrong. You made a mistake and you didn't really read my post. Don't do it again.


I too tried spacemacs and loved the initial 30 minutes. And then I wanted ESLint, and maybe even TabNine for autocompletion. After several hours looking up random gist files I gave up. I don't get paid to edit lisp configs to get my IDE to the usability level of the one my company already pays for (IntelliJ). It's a real shame, but I just don't have the time or energy to deal with those configs.


The Oni editor [1] based on NeoVim seems to be aimed at something like that.

> Onivim 2 aims to bring the speed of Sublime, the language integration of VSCode, and the modal editing experience of Vim together, in a single package.

Currently in alpha, but according to this blog [2] pretty usable and has support for VSCode plugins too.

[1] https://github.com/onivim/oni2 [2] https://seanchen1991.github.io/posts/onivim2/


does it really get to the point where it has everything that say CLion has?

No, it doesn't. There are probably other reasons to try emacs but 'as capable as a JetBrains IDE' is not among them.

As it stands right now I end up using both an IDE and vim.

If you think of it not in terms of text editing but as "tool that operates on files" and "tool that operates on 'projects'", it makes more sense that many (most?) people end up doing something like this.


Yeah I can think of it that way. But I don't want to. I want a batteries included ide as lightweight as vim and as powerful as Clion, not two tools.

Currently you see a bunch of programmers divided into two camps. Those that prefer the vimish style and those that don't want to deal with the yak shaving and prefer tons of features.

The thing is these qualities are not actually tradeoffs in principle they are only tradeoffs by circumstance.


Why not the IntelliJ Vim plugin with Clion? I think the better distinction is Vim for editing text, IDE for performing non text editing tasks.


It's less about the key mappings and more about the portability and lightweight nature of vim. So Clion runs on java and is really heavy while vim can be spun up instantly while you're sshed into any machine. I want both of these features combined.


Ah, I did not see where development on a remote machine was the constraint. In that situation you’re options are more limited for sure.


I'm pretty sure that given enough yak-shaving, Emacs could be augmented with lots of IDE-like features that happen to be implemented in the main distribution, at least in some form. The question is whether you want to bother, given how obscure that whole area is.


Recently, I tried VS Code with the vim plugin and didn't find it to be too bad. Then again it isn't lightweight, but I think part of the problem is, that every programming eco-system has its own tools and one-size-fits-all solutions are unlikely to be small ;-)

However, it VS Code didn't convince me to give up my regular tmux+vim combination.


Well vscode is written on electron. Your editor in that case is a full blown browser basically.

I see no reason why something as lightweight as vim or emacs can be configured to be as powerful as vscode while being much more lightweight.


IDEA Vim?


I mean the ide does have vim emulation but that's not what I'm thinking about. Try the other direction:

Vim IDEA



> I always tell my students that the one editor they are likely to find already installed on a machine is vim

Well, vi, since it's part of POSIX. Unless you are fine with ed ;)


In many (most?) modern distros, vi is a symlink to vim.


I think all BSDs (net, free, open, dragon fly) use honest-to-goodness nvi[0]. Of course vim is available as an installable 3rd party piece of software.

[0] https://en.wikipedia.org/wiki/Nvi


There’s a vi clone in Busybox too, which whilst not Vim, is still really useful.


Back at Uni I used joe because I was used to WordStar (DOS).

On one of my early jobs I had to telnet to an AIX machine to do some work and, of course, joe was not installed and vi was.

I had almost no idea on how to use it, and by the end of that project I had decided that I needed some vi skills!


I am quite surprised to learn, that vi is actually part of POSIX. I mean that is pretty cool and wonder why someone would down-vote that comment?


The ability to efficiently navigate and edit files while SSH’d into an instance is a very useful skill. You just wouldn’t have the permissions to install your favourite editor and vi is almost everywhere.

I had to learn vi when working on green screen terminals logged into HP/UX and there was no alternative but am very glad I did as I find that nothing as ubiquitous allows me to efficiently change files.

Does that mean I would go around advocating one editor over another? No, whatever works for you. I know vi works for me for editing files.

Would I use vi instead IntelliJ for development work? No, I found the development environment allows me to be more productive on project work.

But I think you’re doing students a favour teaching vi.


I've been a professional developer for 10 years and programming for longer than that. In all of that time, efficiency of editing files on a remote server has never been something I've needed to optimize or been concerned about. Have I had to do it? Yeah, occasionally. Yet when I do, it's almost always changing a config file in a minor way.

Back when I started it was editing the code on a live server so I used textwrangler/notepad++ with an ftp editor.

I don't buy the argument that learning an editing paradigm for this very specific use case (which is likely getting less and less common) at all. This is coming from someone who uses vim bindings in my daily editor.


Depends on what you need to optimise for. Being able to navigate a text file efficiently (i.e. not character-by-character using arrow keys), cut and paste text, save/rename/backup files, and sometimes even to do a diff from within your text editor, are all skills I’ve found very useful. I’m an Emacs user on my own desktop, but if you run Linux servers in this kind of environment and you or your team doesn’t manage them yourselves, then the best you can assume you have is Vim, or maybe Vi. If all you’ve got is SSH, it helps to be able to do this stuff without wanting to pull your hair out. Even watching some co-workers stumble through the use of Vim can be painful enough.


Of course with the ubiquity of cloud and minimal images I think the likelihood of having any but the basic tooling on a remote instance is getting more prevalent than not less and the ability to diagnose/debug issues is getting more important. Might not be a Dev but more of an Ops “good to have” but with more places adopting “you build it you run it” and Dev merging with Ops, I don’t think this is an isolated use case.


Why the dichotomy? IDEA Vim is an excellent IntelliJ plugin. For XCode there's XVim2 and Visual Studio has VisualVim. In fact the pervasiveness of good Vim plugins for ide's is one of the factors in Vim's lead over Emacs.


There’s a decent VS Code plug-in as well


Or even better onivim.io


I used vim for some time could never really get into it. The benefits that it offers over other simple code editors like TextMate isn't really worth the learnign curve.

It pretty much feels like a mini programming language for text editing.


I'm not so sure about that. Yes, I have the hard part of the learning curve behind me, but learning vim actually changed how I write code in a very positive way. Now, I think a lot more in terms of lines and e.g. rogue whitespaces happen rarely. I know that are tools who can remove them, but I want to illustrate, that the editor improved the quality of what I type.

In the end, it depends how much time it will cost you to learn vim and if that is worth the effort and I am honestly not 100% sure, but I wouldn't want to go back to how the world was before.


I agree that vim makes you much more line-oriented, but I'm not sure it's always a good thing. My non-vim collaborators find it strange that my LaTeX files have each clause of a sentence in a separate line.


> In the end, it depends how much time it will cost you to learn vim

Is there really that much to learn? Open file, save file, exit, block select, copy paste, search and replace - thats about 99% of what you do in an editor. 15 minutes to pick up, ipossible to unlearn. Unless you have some other editor ingrained in your synapses. Switching between editors with different shortcuts is a torture.


Actually, the commands you listed are more or less the basics, but the magic comes when you learn about the structure of the commands.

For example, `2dw` is a typical example. So you start with the number of times you want to do something, then you add a verb like `d` for delete and you end with a noun like `w` for word. As you probably have guessed, it deletes the next two words.

Since working with lines is quite common, many commands are executed for a line when you repeat the verb (easy to type). So `2dd` deletes the next two lines.

When you use this language you start using vim. There is still more to explore (e.g. macros), but this is where vim is different.


> I used vim for some time could never really get into it. The benefits that it offers over other simple code editors like TextMate isn't really worth the learnign curve.

https://wiki.c2.com/?BlubParadox


I started programming about 5-6 years ago (I'm a high school student). I started with VSCode, but about 1.5 years ago I switched to Vim for the simple reason that I wanted to live in the terminal. Unlike some other commenters here, I didn't know anyone else who used Vim (or Emacs for that matter), so I learned on my own... (:help is actually good in Vim, unlike many help menus in other software).

vimtutor does a great job introducing vim, and it took me about 1 hour or so to get started.


I have a pretty similar story. I was in senior year of high school and one of the colleges I was applying to had a “sleeping bag weekend” where you could sign up to stay overnight with a random CS freshman in the dorms and stroll the campus.

I saw someone working on their homework and their terminal had colored text and it blew my mind (I had only ever seen cmd.exe using black and white with that ugly font).

The summer between senior year of high school and starting college I installed Ubuntu and googled that program called “vim” that freshman had demoed to me. From there it was just like you say: vimtutor and reading :help pages, and now almost 10 years later I can’t imagine trading Vim for anything.


I wish there was a dedicated, light text editor that could be comfortably used as a typical vim config but was fully compatible with a windows/mac paradigm for discovering shortcuts or standards (e.g. with the mouse or using standard keybindings). Gvim isn't quite there but close. This fictional editor should still be usable by anyone in a terminal but should be used like vscode as a standalone tool and yet very, very low resource, low fuss. There just isnt such an editor. Vim itself is just too hard for a beginner. It took me far too many years to know it and Im still learning years later...but I'm hooked now and struggle to edit text using the mouse, end, home, delete, enter, tab and ctrl-chords. I'd recommend it to anyone but more as a fun learning project; an esoteric plaything with real-world applications that give you a bit of an edge oftentimes.


onivim.io


I switched to Vim in 1994. At that time, I had been using Emacs for a bunch of years. One day I decided to cross over to the other side.

I hunted down all the readily available open-source Vi implementations, downloaded them and compiled them all. I tried Elvis, Nvi, Xvi, Vim and a couple of others I don't remember.

Vim was the best, by a long stretch, so I continued with that. I found the built-in tutorial very handy; I went through that, and within a week I was proficient.

A couple years later, I started seeing Vim in GNU/Linux distros as the default Vi implementation.


In early 2000th I used to admin quite diverse network, including rare and exotic *nix systems, early Sun machines and HP-UX. One thing I was sure about - every of them had 'vi' after installation.


i only had one good teacher in high school and I consider myself lucky. the students of the writer of this article have at least one good teacher as well. personally i only know vim enough to know that I prefer emacs, but I agree with virtually every point of this article. a further point I would make is when you learn these technologies(a text editor/cli/unix tools), you will literally use them for the rest of your life. With no subscription fee!


Would this author happen to have a blog post of how they teach it? I'm curious.


Not sure about the article in question but I would highly recommend ':help user-manual', it's actually mentioned at the end of vimtutor. It can be worked through chapter by chapter and covers all of Vim.


Ya that would be really helpful. I've picked up bits and pieces of vim over the years. Recently, I even installed vimium on Chrome and the vim extension for VS Code in an attempt to get better at it.

It has been quite effortless to delete or replace words or lines but every time I've tried getting more adventurous with it - say, surround every line of text with double quotes etc, I end up finding the commands unintuitive or hard to remember.

There's also an issue with my older muscle memory of `CMD+Z` which works on a different stack than `u` and `CTRL+R` and I end up messing up my code.


I guess I’ve got used to working with both sets of shortcuts but I miss the Vim undo system in other apps.

It’s worth noting that u and ctrl-r don’t operate on an undo stack but on an undo tree.

So if you have a series of edits and undo them all then do something else you can still get back to where you were before.

Use g+ and g- to walk the tree and the Gundo plugin is gives you a nice visual diff interface.

So having a separate shortcut and “stack” is actually a great feature of Vim IMHO.


Wow I didn't know about the undo tree! That would have definitely helped in a few scenarios


This is really cool, and I had no idea about Vim using a tree instead of a stack for undos. I'll check out Gundo.

Do you have any other similar recs that would help for learning?


Drew Neil’s vimcasts.org is a mine of useful tips.

His book Practical Vim[1] is particularly good because it teaches you the “vim way” without plugins.

Not that there’s anything wrong with plugins, I use a load of them, but there’s loads you can do without them.

1. https://pragprog.com/titles/dnvim2/practical-vim-second-edit...


vim generally doesn't need any of those fuzzy file finders that most people use. If you add

  set path+=**
to your vimrc, and open vim from the top level directory for your project :find <unique_filename_part> will just work

Setting up ctags will give vim some IntelliSense-like functionality that people tend to miss from their IDEs. More info here: https://andrewra.dev/2011/06/08/vim-and-ctags/


> vim generally doesn't need any of those fuzzy file finders that most people use. If you add > > set path+=

Be wary of this, it can end up being quite slow. Here is an excellent write up detailing the usage of the path setting.

https://gist.github.com/romainl/7e2b425a1706cd85f04a0bd8b389...


vim is not for everyone. The cartoon poking fun at Emacs chording doesn't resonate with me at all. The statefulness at the core of Vim is maddening for me, where Emacs chords, perhaps because I have been a musician, are relatively easy for me.


noone cares what editor you use, text editors have marginal impact on the product or service that you are developing.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: