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?
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.
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.
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.
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 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.
- 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.)
My mentor was vimtutor.
Seriously, learning basic vim takes 30 to 60 minutes with vimtutor.
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.
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)
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.
But I have not switched to emacs(evil mode ofc.) due to mostly philosophical differences and i completely just hate the defaults..
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 :)
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.
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?
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!
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.
It would probably be doable for other languages, if you were so inclined
https://micro-editor.github.io/
HN discussion: https://news.ycombinator.com/item?id=23334190
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.
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.
> 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/
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.
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.
However, it VS Code didn't convince me to give up my regular tmux+vim combination.
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.
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...
This is unfortunate, vim macros are fantastic for reformatting text.
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.
Well, vi, since it's part of POSIX. Unless you are fine with ed ;)
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 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.
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.
It pretty much feels like a mini programming language for text editing.
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.
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.
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...
I don't see any evidence for that.
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.
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.
vimtutor does a great job introducing vim, and it took me about 1 hour or so to get started.
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.
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.
- 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 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.
