I first gained access to a UNIXish system in the fall of 1988, which was some SunOS4.x variant I believe. The shell was csh, the editor was vi, and I had no idea what I was doing, nor was there any help in my immediate area to be found. And no, I didn't know about 'man' yet.
Somehow I discovered that 'vi' was the way to edit things, but I didn't know how to exit, so trial and error led me to pressing control and z at the same time. Bingo! The shell is back.
After some days of building up background suspended vi instances, the system administrator came in and gave me a few pointers.
Holy shit, ATT 3B2, I haven't heard any mention of those in a long time.
So, six years later, in 1994, I found myself as the UNIX system administrator for a large (at the time) datacenter at Keesler Regional Medical Center, Keesler AFB, Biloxi Mississippi, where we had quite a number of 3B2s. They were, in fact, the only machines we had that were rated for classified data.
If memory serves, they ran AT&T System V release 3 UNIX.
We also had, among others, DGUX, SCO, AOS/VS, Sun and Vax/VMS servers. Of course each of AOS/VS and VMS had their own, non-UNIX operating systems.
Funny story: we put word out to AETC (Air Education and Training Command) that we needed more 3B2s, and a few months later, some pallets arrived from Homestead Air Force Base, which had been destroyed by hurricane Andrew a couple of years prior. These servers had green and brown smears on them. Clearly they had been submerged by hurricane flooding for some period of time. So we ran a long extension cord out to the parking lot, plugged them in and stepped back. Much to our surprise, several of them actually worked, and later ended up racked in our datacenter.
For what it's worth, I also used DG/UX, MV/UX and AOS/VS on Data General equipment (MV/10000, MV/4000) at the University of Washington in the 1985ish time-frame.
I remember porting many BSD 4.x utilities to MV/UX. What a learning experience, with the MVs differently-formatted byte vs. word pointers.
Wait really? I'm a lifelong emacs user too[0] but it only tells you how to exit if you open it without a filepath. If you're in a file because EDITOR was set to emacs by some other person and you try to exit it just says "C-c" or "C-c C-c is undefined" when it should just tell you how to exit. Or even better why doesn't it just exit on "C-c C-c"?
[0] Well I might write my own emacs-inspired, ruby enabled editor one day, but that's another story.
That's true. If you tried Control-H, you'd get a lead. Unless of course that was mapped to your main backspace key, which sometime happened in the bad old days.
As to why Control-C doesn't just exit the editor, I suppose it was generally considered to be a bad idea. And in the case of emacs, it might take five or ten minutes to restart. :-)
(It's worth noting also that GNU emacs ran on many platforms, some of which for which Control-C was not any kind of "kill my process" character.)
Yes, I was able to save the file using ZZ rather than :w
It's been a long time, but I was probably hung up on not being able to experimentally figure out : commands, where I was able to figure out control-z and ZZ.
In the opposing vein, as an Emacs user the best configuration I ever made was to rebind C-x C-c to execute-extended-command instead of kill-emacs. It was way too easy to (even accidentally!) kill emacs with a sweep of a finger. And I probably use a few hundred execute-extended-command calls for each kill-emacs (which I now have to type manually as 'C-x C-c kill-emacs' - no problemo).
A similar optimisation was with tmux to bind the prefix to C-z. It's in a handy location next to ctrl and I very rarely use suspend anyway (which is still available as easily as C-z z). Stretching your fingers between ctrl and b (the default prefix key) merely made me wonder who the heck thought of something like this?
As for vi, I made a point of learning to use it enough to do useful work editing config files and small texts. Every once in a while another application brought up 'vi' for some reason (maybe I lost VISUAL or EDITOR while sudoing or the app was looking for another variable) and I could never exit the damn thing.
So instead of just learning :q and figuring out how to make the particular program or script relaunch another editor I thought it's the path of least resistance to just edit with vi directly. It has been an incredibly handy skill: I never use vi for anything larger but these days I actually do 'vi /etc/fstab' myself instead of calling for emacsclient.
However, I've been toying around with the idea of eventually writing a minimal 'vi' clone that you cannot exit. I'm sure there's pent-up demand just waiting for one!
Usually people don’t remap the menus much so I think if you clicked around the modeline enough you could pull up some help and eventually figure out the binding for kill-emacs or execute-extended-command.
| However, I've been toying around with the idea
| of eventually writing a minimal 'vi' clone that
| you cannot exit. I'm sure there's pent-up demand
| just waiting for one!
If a user space program can be truly unexitable without restarting (including the possibility of killing it through another shell, of course), then would you consider it to be a bug in the operating system? Seems a reasonable conclusion to me.
I once played a maze game on X where the maze would literally not allow the mouse cursor to go through the walls so it would be taken hostage. The only way to continue your X session was to solve the maze. That was quite funny. Oh, well, there could have been some other keys that would have done something about it but it was fun anyway.
At some place I worked there was a policy that a small prank was allowed if the workstation was not locked when someone left. I'd almost recommend that policy for some places.
Acceptable pranks would be things like:
- innocent videos (annoying videos for toddlers etc)
- change Spotify playlist from rock to childrens songs or rickroll or something
- open MS Paint and draw something (those pranks weren't necessarily small, we got three huge monitors side by side on those workstations)
- etc
Unacceptable pranks:
- anything that wasn't possible to revert in a hurry
- anything a customer couldn't see (we were on display :-/ )
At another place I know someone sent a mail to the team from someone elses account that they would bring cake the next day.
I once burned myself by doing what I thought was the obvious thing: leaving a message in a text editor and locking the machine. Turns out for some reason he couldn't unlock it after it had been locked that way and he needed to leave the campus to have IT at the main site unlock it. (When he locked it he always did it by closing the lid instead of through the system menu.)
As an aside you can also make a (non-elisp) scratch buffer on the fly: when you switch buffer just enter a name that isn’t taken (I usually use b, bb, bbb, ...)
In the rest of the universe, going to the beginning/end of the line is mapped to the Home/End keys (fn+left/fn+right on Macs), and I do prefer it when my thing does things in ways that roughly correspond to how the rest of the universe does them if there's no compelling reason to do otherwise.
I know, because I have triple-shift-press mapped to shift lock on my Ergodox. It's... usually better, but sometimes I type a @#$%@#$% swear word when I mean to enter a number.
I have remapped capslock to be an additional ctrl so I hit C-z easily with my pinky + ring fingers.
C-a (like in screen) would be even better but as others have pointed out it masks going to the beginning of line which is very common.
C-z is very rarely needed. C-q/C-s would be good candidates also as I don't think I've ever needed flow control in this century nor the last one, for that matter.
My understanding of the history is that the developers of tmux were using screen to develop tmux, because tmux didn't exist yet, so they needed a non-conflicting keystroke.
Obviously they could have switched before a general release, but I guess they had gotten used to it.
Also, many older production machines don't have tmux, so nesting a screen session happens. This is starting to not be a thing, but it was a thing for the trailing 10 years.
That was how I'd exit vi for a long time. Often "killall vi" because any other vi instances running would in any case be by accident.
I once caused a near rebellion of vi users when I was running an ISP and symlinked vi to emacs on our shell server because I was sick and tired of it...
Had the same issue with C-x C-c; I remapped mine to C-x C-c C-t because it worked for me as a mnemonic (assuming a "soft c"): "ex-s-t" => "eckst" => "exit"). Major productivity boost!
I did something similar w/ tmux: map the prefix key to C-a and map CapsLock key to Ctrl (never found real use for it). So Ctrl-a (actually CapsLock-a) is very ergonomically pleasant.
The accepted answer here [1] is what got me to see the light. Once I realized how composable the main commands are, vi became kind of fun.
I still prefer Emacs because of macros and org-mode, but I no longer fear vi when I'm doing a quick edit, editing a huge file, or on a emacsless new machine.
I have tried to start using vim so many times and failed. Even this year I thought to start using vim. Daily I open vim once try to do something new with it. Although I don't have much of hope that I will start using it an soon.
As a sysadmin, not a programmer, what I found helpful for learning Vim was not to try something new each day, but to find one or two commands that were valuable enough that I would at least open Vim somewhat regularly. The two that did it for me are delete line (dd), and change inner word (ciw), both extremely helpful for config file editing, especially when combined with repeat command (.)
After learning these first simple commands, it was enough to get me to open Vim at least a few times a day, which then motivated me to start learning more of the commands and it just snowballed along. I still only know probably 25% of Vim, but I feel incredibly comfortable in it now and rarely run into trouble when doing beginner to intermediate editing tasks.
As a fellow sysadmin, I would advise to learn vi properly then switch to Vim because the former is pretty much everywhere, and for example you could mess the file with cursor keys in Insert mode instead of using hjkl in it.
That's good advice, but in all practical situations I have been able to use Vim directly or know enough vi to get by, though I am much less comfortable with it.
I don't touch type, so hjkl, even though I understand the benefits, has never been my preference. Perhaps it's the gamer in me, I've never had trouble using the arrow keys :)
One neat thing this misses is that in ASCII, H is left, CTRL-H is backspace (which goes left while doing a thing); J is down, CTRL-J is linefeed (which goes down while doing a thing, sorta). It ends there, unfortunately - I don't see a good connection between vertical tab and up or formfeed and right.
I finally started using Vim sort of by force, and am already becoming proficient with it after a few hours (and liking it). The reason was that my ISP sent me a cheap Chromebook for free, and I've started using it for coding during my commute (and relegating my old laptop to my music studio). A few days ago there was a ChromeOS update that seems to have killed the ability to connect to code-server (a VS Code server) from the browser, no matter what I tried, and then I tried my old trusty Emacs and I can't get MELPA to detect go-mode at all.
Infuriated by all of the above I found a nice tutorial on how to set up Vim for Go development, used vimtutor, and now I've been able to do non-trivial amount of work while on the train. I actually rather enjoy vim now.
I very much enjoyed the first level. Already quite proficient in vim, I balked at the cost of the full game - but it might well be worth it in your situation.
I'm not sure if I should mention it here, but in case some people are not familiar -- these lines make using vim a very easy experience for those used to CUA editing interfaces:
set nocompatible
source $VIMRUNTIME/mswin.vim
behave mswin
It doesn't really change the command mode if you're used to traditional vim, but you can use shift-arrow keys to select text in VISUAL mode, use CUA commands like C-c, C-x and C-v, etc. Keys like Home, End, C-insert, and S-delete also work.
I first used vi / vim about 30 years back. There are other editors that provide fancy features and I do use them routinely but there is no day I have not started (and exited) vim. Get used to it.
I've made quasi-regular attempts to get truly comfortable with both Emacs and Vim at various points over the... last two decades, honestly. Strangely, I was always a little more comfortable in Vim, even though the other editors I've been comfortable with through the years have been modeless. Last year, though, Vim actually took for me, and I think there were three reasons:
(1) Buying the book Practical Vim from the Pragmatic Programmers, which is aimed at people who kinda-sorta know Vim but don't know much of Vim. I still haven't truly internalized a lot of what I've read, but just understanding the magic of ":find", "." and a slightly greater number of the Ten Thousand Ways to Select has been amazing.
(2) Trying to do as much as possible with "native" commands rather than plugins, then adding a smaller number of considered plugins back in.
(3) Having a real project -- of sorts -- to work on and sticking with Vim for that project. In this case, the project was going through the entire Pragmatic Studio course on Rails 6. (It's good.)
I'm pretty sure these same three steps would work for learning Emacs, too. (Obviously with a good book on Emacs in step 1, not Vim, yes, yes.) But I'm actually pretty happy with Vim.
Also, the proper way to quit MacVim is clearly to select "Force Quit" from the Apple menu.
One day several years ago I found a ~15 year old laptop on the side of the road and wondered what I'd do with it. 300MHz processor, "what's Ethernet?", and I didn't have the little pile of flaky USB Wi-Fi dongles I have now.
And it was only through attempting to actually install from the Slackware CDs I'd burnt several years earlier that I discovered the scratches on them were unfortunately not just decorative scars.
So: gcc, corrupt. g++, corrupt. Python, corrupt. Perl, corrupt. sed, ...not corrupt. grep, also not corrupt.
I love working on little projects. At one point I noticed that installing specific packages quickly and easily wasn't straightforward because I couldn't see what was already installed.
dialog was among the uncorrupted, and I wondered if I might use this to show installed and uninstalled packages side by side.
That was when I discovered the info pages were also intact, and that sed and grep both had excellent info documentation.
Unfortunately I deliberately gave up working on the project after a few days, as I developed headaches from staring at multiple ~5-6 line (ie, ~480 char) monster regexes over the course of a week or so. (Imagine multiple blocks of modem line noise each 2-4 times longer than http://bash.org/?464385 and you're in the ballpark.)
I do plan to finish that script at some point though (when I regain access to that laptop's HDD). It was only 5 sed commands and 4 grep commands...
> - So, how did you learn Vim? I heard there's quite a learning curve.
You can go through the interactive vimtutor.
Type :help tutor
Or you can just type :help and find the link to the vimtutor. If you are using gVim, then it should be one of the menu items ( maybe under help? ).
My suggestion is to just search for basic vim cheat sheet if you are getting started. There are also youtube tutorials online. Sometimes watching someone work with vim can help you get over the hump.
> - I just open it, but I couldn't figure out how to quit.
:q to quit.
:q! to quit without saving.
Remember to hit ESC to get back to the normal mode first if you are in other modes.
When you are comfortable with Vim then you can go on to some of the advanced vim topics. Also, in the beginning you might have to ddg/google/etc a bit. Good luck.
It's amazing to think how far we've come since June 2018 where the record was just shy of three minutes (https://www.youtube.com/watch?v=TLbfqZBL8t8). These new strategies could allow experienced speedrunners to exit vim in times of 10 seconds (or perhaps less!?). I'm excited to see how this progresses, the vim speedrun community is vibrant and creative and I've no doubt we'll see a sub 5-second run within my lifetime.
I'm confident we're at the dawn of a new era of AI driven vim closing.
My first attempts ended up with my bot buying stock in a clorox brand before posting questionably racist comments to my twitter, but these are minor concerns on the journey.
I'm streaming the process on twitch but please note that donations won't be considered as seed capital for stock assignment
But who would support it? While a formally verified functional approach may satisfy one's doctorate requirements, the author will graduate and move onto blockchain development, leaving behind an exit-vim code base that no other engineer could possibly understand without the equivalent training. Upon receiving said training, an engineer would also take newly acquired doctorate and also move onto blockchain development. Essentially, supporting a formally verified functional approach to exiting Vim creates a pipeline of well-credentialed and rigorously trained professionals for blockchain development. If Vim were, however, put on the blockchain, we may be able to address this concern and you can get what you wanted.
Since the real world is not necessarily deterministic as demonstrated by the methods using random(), I hope to see more development in stochastical methods describing parameters of probability distributions of successful exits.
In the face of vim's unyielding resilience to exiting, I think we may need to devise a new algorithm for this using quantum superposition. I heard IBM can help with that.
OMG I use pretty much the default settings in vim but set mouse= is one of the only 2-3 things I put in my vimrc!
The macbook pro and old thinkpads are the only laptop computers with decent built-in pointing devices, all the others always end up coupling with my palms and randomly munging my code!
One of my Computer Science lecturers had a rule: use Vim for all development for his class whilst on campus, and if caught using any other editor/IDE – or committing any artifacts showing evidence of such – we would lose several percentage points from our final mark for his class.
Harsh? Perhaps. But I can’t thank that lecturer enough for that rule. He converted a mostly IDE-wielding class into one that actually appreciated Vim, and most of us still use it or its key bindings.
Edit: this was in 2018, when VS Code, etc. were already popular.
That's stupid and elitist. There's no reason to force students to go against IDEs that they're already used to, but also the general method of navigating around a computer which they're probably used to from MS Word etc.
It’s a college class in which students are supposed to learn something new, that seems like a perfect example of a situation where you should be forced to do something outside your comfort zone.
I don’t interpret that as the college professor saying this is actually the best way to code, just that forcing students to struggle through it is a learning experience.
> It’s a college class in which students are supposed to learn something new
Unless the central thrust of the course is supposed to be the mechanics of a particular dated editor, the restriction described seems to be a distraction from rather than an aid to what the students are supposed to be learning.
It doesn't make any more sense than a social science course where the deliverables for most assignments are essays mandating WordPerfect for DOS. Sure, you'll learn something you might not otherwise, but it's a distraction from what you came to the course to learn.
I wonder how you feel about age discrimination. Old != bad.
I started using Vim when I was 14; I was the only one in the class who wasn't using an IDE. Vim (perhaps combined with a language server if you're okay with the complexity) runs circles around bloated IDEs like IntelliJ/VSCode. Unix combined with a tiling WM is the best IDE in existence.
The professor in question is likely doing the students a service by showing them the advantages of minimalism and function-over-form over the trend of bundling an OS with every "app". Many students today only feel comfortable using software that saturates their synapses with colors and animations; having to use Vim for a semester forces the good ones to realize that maybe, just maybe, function should come before form. Maybe 10k lines of C or POSIX shell solves a problem better than a VC-backed Electron app.
To continue your analogy, WordPerfect and DOS, unlike Vim, aren't better than today's tools. What would be an improvement is LaTeX/BibTeX for writing essays. Once I realized how much work was automatically done for me--from Chicago-style footnotes/endnotes and auto-generated ToC from headings, the time I spent formatting my papers dropped to zero. I would absolutely incentivize students to use these tools over "modern", bloated word processors.
Minimalism for the sake of minimalism isn't what I was arguing for. If it were, I'd say that every paper and program should be written with `ed`, the standard text editor [0].
What I was trying to say was that if minimal solutions run circles around bloated ones thousands of times their size, and when it takes a startup and two funding rounds to develop something that does exactly what tools did three decades ago less efficiently, then maybe Braithwaite was on to something:
> “It’s a curious thing about our industry: not only do we not learn from our mistakes, we also don’t learn from our successes.” -- Keith Braithwaite
Modal editor are not dated. You’re saying this as if the command line itself is dated. It’s not, casual user can go ahead and use Windows or Mac, but shell and she’ll editors will not in the foreseeable future be dated.
I suspect the rationale is that, depending on the language you're using, some IDEs "help" with coding to the point where they're correcting your mistakes and even writing parts of your code for you. This is pretty much a selling point for everything JetBrains makes, and arguably even Visual Studio Code rubs against the edge of that if you're using a language that's well-supported by IntelliSense. The central thrust of the course is presumably how to write code yourself, and the case could be made that learning with an editor designed to routinely save you from yourself isn't going to be as good as an editor which, well, isn't.
(This is setting aside the argument as to whether Vim is a "dated" editor. Vim is an old editor, to be sure, but forget WordPerfect -- it's not as old as Microsoft Word is!)
I've found myself learning stuff better when there is no IDE correcting me all the time and auto-generating stuff out of thin air. IDEs are awesome once you know what you're doing but I do also see the reasoning for forcing to use an ancient (and still quite powerful) editor.
Disclaimer: I do most of my coding in Vim but use IDEs every once and a while.
If this was at work, or if this was for every class at a given university, I'd agree with you. But, in a place where you go to be challenged intellectually and open your mind, why not? This would be perfect if the same professor forces everybody to use a specific IDE in a different class...
I disagree completely. When I took CS036 in first year engineering, it was a C++ course that used Visual Studio and while I received a good grade on that course, at the end of it I did not know how to invoke the compiler from the command line. I only knew how to build software from the drop down menu in VS2004 or whatever version it was.
Sure, but invoking a compiler from a command line is something you can easily pick up from a coworker or an internet tutorial.
The primary focus of an intro engineering course is (usually) about the theory and structure of computing, along with general techniques for writing code.
Learning about various build tools distracts from that focus.
EDIT: Also, you seem to be implying (apologies if I'm wrong) that invoking a compiler from a command line is somehow "better" than using IDE. Why?
My intro course used BlueJ, which is (was?) some sort of dumbed down Java IDE specifically for students. The thought was that dealing with all of the crap surrounding software development, like make systems, editors, compiler flags, etc was a distraction from learning basic programming constructs. Looking back I agree completely. As a new programmer, things like compiler flags are pretty much black magic. You don't really learn anything by reciting magic spells.
Learning development tools like the CLI, IDEs, debuggers, linters, et. al. should be required for a CS degree. I don't think an intro course is the right setting.
I’ve seen Java developers completely lost with no idea where to start debugging an installation in a lab environment because they had no IDE, JDK only. Sure, you might argue that it’s an unlikely scenario, but never say never. CS is one of many fields where having a basic understanding of how things work at least a couple of layers of abstraction down is a good thing, and at least could save potential embarrassment.
You're not wrong, but I don't see how forcing people to use vim solves this problem. If anything, you risk having a whole class of students who can only do things the vim way. I'll grant you that you're much more likely in a lab environment to have access to a POSIX system so you can use vi or whatever, but you could also wind up in a shop that dictates its devs use a specific IDE.
I'm in full-agreement that it's a good thing to have a basic understanding of how stuff works, but I'm not sure how enforcing vim over VSCode or Sublime or [insert your favorite editor] necessarily teaches that. It teaches adherence to vim.
I'm of the opinion that programming tools are very personal -- that's why there are so many debates and that's why we'll never have universal agreement. I know my way around the command line and I'll suffer through vim if I have to (it's fine. It's just not my editor of choice), but if I don't have my dotfiles or configurations, I'm not going to be very productive either.
I'm fine with saying, "don't use an IDE in my class, use a text editor" -- but I find it draconian and ridiculous to insist upon a specific text editor.
I should have been clear that I lean toward your side of the issue in that a blanket policy for the entire term does seem a bit extreme but completely without value. If I were pushed to defend the instructor’s policy of a particular editor, vi is nearly certain to be on any Unix installation. Not necessarily how I would (or have) done it, but the approach is not without value.
My preferred Unix editor is the vi family. I wonder whether emacs people are less sympathetic.
I'm glad you had a good experience with this, but I can tell you right now that if I had a professor insist I couldn't use my own tools for his class out of what appears to be nothing more than "you will use what I force you to use because I believe only REAL programmers use vim," I would be the type of student who would take great pleasure in using my text editor of choice discretely and doing whatever I could to ensure there was no proof that I was using my tools of choice.
I'm fine if a professor wants to say "we're not using IDEs, we're using text editors in this class and this is why" -- but to dictate the editor would be akin to being told what type of pencil or pen I could use to take hand-written notes.
It reminds me of one of my writing professors who insisted that all papers presented to him be formatted in Arial. Arial is a bad font, so I asked if I could use the metrically identical Helvetica, and he refused. I still submitted my papers in Helvetica anyway and he never noticed.
(I'm not claiming this is a mature response, FWIW, but a core part of my personality naturally pushes back on anyone telling me I can't use something for a wholly arbitrary reason or because they want to enact a ridiculous level of control.)
I am a Vim user, and if I had a group leader tell me that I had to use some different editor because we are all learning how to do this job together, and that learning how to use the editor properly was part of learning how to do the job, I would do what he says. At least for as long as he stays in the room...
On the other hand, we had an architect who has since retired that said, if it was up to him, all developers across the campus would use the same programming language, editor, and configuration. Thankfully it was not up to him, and we still have this lovely diversity of opinions and tools that signals it is encouraged for specializations to develop, thus making sure that we are not all replaceable cogs in an exceedingly boring machine.
But the memory of this man's twisted vision remains with me, and it strikes me that the leadership still would seem to prefer if we were in fact fungible units of work-capacity, without any distinctive features or unique characteristics differentiating us from other developers.
IMO if you learned to ensure there was no proof of different tools, you learned an equally valuable lesson; I would mark you down for example if I opened your file and found a bunch of CRLF line endings, or some other similar obvious linting violation that was prevented by an editor configuration you were supposed to have installed during the class. But if you applied enough attention to detail to make sure this was not possible, in a way you got the point (and also for the purposes of the grade, you definitely got the point!)
I would do as they said if they convinced me that they had sound reasons for the choice. I don't think they'd be able to come up with sound reasons for dictating vi specifically, over a more lenient requirement, though. And being dictated to like that without sound reasoning behind it would instantly make me rebel. Unlike the other commenter, I would not do so quietly - I'd be more likely to make sure to use whatever he'd take most offense at in front of him, and seek to rally others to that cause.
I just sat through a two day training/workshop session called "Design Thinking" during which we learned about techniques to interview stakeholders, and how to empathize with their needs and concerns (specifically without solving the problem at hand, or trying to solve it.) My perception is that I am closer to the problem than most of the other classroom participants, and I have more than enough experience to solve it by myself, without any help.
It was very difficult to follow the guidelines for the exercise and refrain from simply going ahead and solving a problem that I've solved many times before in a way that was familiar to me. In my view it would have taken less time to simply solve the problem than to engage in this seemingly "pointless" exercise, but I do think I understand better after taking the time to convince myself that those other points-of-view have merit and should be taken into account.
Maybe I simply have a case of the old Stockholm syndrome, but between you and GP, I think I'd rather have a more cooperative and acquiescent person on my project team, for the grade. Sounds like a bikeshed argument. First we said the choice didn't matter, that it was less important than the actual programming content of the class; now we're actively combating and making a big stink until someone does some argument dance about it, and convincing happens, so the justification for the specific choice is judged acceptable. (And I guess you've already dug in your heels by this point, and won't be convinced no matter what the reasoning offered.)
What would be your reasons for rejecting vi, specifically? It seems to me that we've actually rejected the idea that editor choice is unimportant; if it was so trivial and doesn't matter which editor, we probably wouldn't be fighting about it, nobody would mind the seemingly arbitrary decision. Nobody would ask for sound reasons to justify.
I don't like vi, but that's besides the point - I'd fight it exactly because I'd see it as a pointless restriction that indicates dysfunction, and I'd see that as reason to protest it in itself.
If the point of the course had been to learn vi, or the teacher had given a compelling reason for why specifically vi, rather than less specific instructions, then I might have accepted that if their reasons were good enough.
Everything I'm about to say, I say as a Vim/Evil user who avoids IDEs like the plague. I like Vim. I like composing commands on the fly, I like modular editing, I like that I can magically format CSV files with quick macros, and I like jumping around my editor like I'm Spider-Man. Heck, I swapped out my window manager with EXWM and Evil just so I could use Vim-style modular commands everywhere.
But learning Vim isn't related to learning how to program. In that context, it's a pointless distraction.
Be honest -- when was the last time that you or anyone you know had a programming assignment at work and came back to scrum a week later saying, "I'd have finished this, but navigating around my editor just took up too much time?" >95% of programming is going to be bottle-necked by the speed you think, not the speed at which you can edit text.
So it's like forcing all of your students to learn Dvorak, or to submit all their written work in cursive. Undoubtedly a few students will thank you for it at the end of the class because some people do get real value out of learning those skills -- but just as many of them will say you wasted their time, and they'll be right. I write in cursive too; it's an objectively faster, more pleasant way to take handwritten notes. That doesn't mean that learning cursive has anything to do with learning to write books.
To any professors on HN reading this: if you're teaching a programming class, please teach programming. Because if students just wanted to learn something new, or to be forced to struggle with something outside of their comfort zones, there are a lot of cheaper ways than college they could do that.
Even with that goal -- a programming professor can't come up with any outside-the-box assignments more related to their subject than "learn Vim"? I can't fathom that kind of lack of creativity in a field this broad.
This is more or less what I did, but under my own motivation. I charged myself to do all my CS homework in vi and had a copy of O'Reilly's Linux in a Nutshell at my side. It didn't take more than a couple of semesters and I didn't need the book at all.
I used to be a vim evangelist before, but after seeing some of the people at my lab writing code as fast as me in Sublime Text, I’ve decided not to participate in editor wars anymore.
In 2018 - this is so bad that it deserves some kind of disciplinary measure from administration.
This is absolutely unacceptable for students needing different accessibility enabled tools other than vi /vim.
For example, if using an alternative screenreader or a vocally/sound enabled ide or if needing to interact with a text editor via a brail enabled tool that doesn't work with vi, does the student just get failed out? That's a lawsuit waiting to happen.
...This is a bit of an overreaction. I think it's safe to say that the professor won't fail any blind students simply on the basis of being unable to use Vim.
Jokes aside, shouldn't the page start with actually teaching how to quit vim?
The page is considerably popular to show up on a Google search. I imagine the frustration of a beginner actually trying the first examples and not getting the joke immediately.
This kind of advice confused me early on because I didn't realize the : was part of the command for way too long. For beginners, you might want to spell it out further as: "shift and the : key, then qa, then Enter"
You're only targetting old 1970s terminal users, there, though.
If you wanted to also help slightly more modern users who are used to CUA conventions from GUIs, you would have the [F1] key bring up some form of help screen, which said something like "Get out of Vim: Use :qa!" at the top.
You're only targeting old 1990s GUI users there, though.
If you wanted to also help silghtly more modern users who are used to discoverable-UI conventions from mobile apps, you would have it so shaking your device brings up some form of chat bot, which would suggest asking it how to quit Vim.
I'd bet that most people who get stuck don't start vim themselves though. I taught (the basics of) git to a bunch of students recently and the first time we did a commit I had to go around the room and show people how to operate vim. I bet the same happens when new people use visudo, etc
You get the same thing in vim, but only when you open it without a file. Chances are, you only do that when you're already a vim user, and most non-users will be confronted with any random program opening a file in vim for them to edit (visudo, git commit, etc.)
The best thing that can happen to a beginner is they continue being frustrated with vim, quit it before they get in too deep, and just use shitty idees like the rest of us trash.
My first go at vim was an accident. I was using git and ended up there. I later tried to change the editor invoked by git to something else, but have concluded that was dumb and the only real option is to learn vim. It's still on my todo list. As is the actual OSS work I want to contribute after climbing this hill. It should not be this way.
The question is not "How" but "Why" you would want to ever do that in the first place;-)
Many years ago I knew a university professor and students said about him he might leave uni occasionally but he sure never leaves Emacs. Some live in Emacs, some live in Vim.
Emacs users live in emacs, but vim users usually live in the terminal, not directly in vim. Good thing there's a terminal version with vim bindings of pretty much every program out there :)
(As I finished writing this, and was about to type ^[fG to submit this reply, I couldn't help but smile a bit)
I live in a different universe to you it seems. The only vim command I know is :q.
Honestly, I tried several times over the decades and walked away with my head buzzing.
PS: I don't live in emacs either!
What I do love in both camps is how the explanations begin... "All you have to do is...[insert irrational (to non-vim/emacs users) command]" which makes me laugh every time.
Love the article, which ironically proves my stance of me keeping well clear.
I know some basic commands and know it well enough to edit git commit messages and interactive rebase (`ddkP` is probably the most advanced command I know). But I've never thought "I prefer this over my regular editor this is amazing". I just don't get the satisfaction.
And of course I'd have to dive deep into the ecosystem in order to get the same benefits that my main editor provides out of the box, like idk, cmd+click to go to definition, or error reporting like squiggly red lines.
> And of course I'd have to dive deep into the ecosystem in order to get the same benefits that my main editor provides out of the box,
To me, vim shines as a modal editor, not an IDE. I use it for two purpose:
1. quick editing configuration files, or single file scripts
2. an editing mode in an IDE (mostly VSCode)
The main benefit of vim is to save you from using the mouse or the touch pad. I touch type, my indexes rest on F and J, and I can do pretty much anything without leaving the keyboard, without using the arrow keys, and keeping my eyes on the screen. It's not something I'd know how to do without Vim. If I'm using the arrow keys, I need extra-time to relocate the "J" key, which breaks the typing flow.
My hypothesis is that vim style work (without moving a wrist even a bit) is the reason people get carpel tunnel. I anecdotally see far fewer (none?) People who don't do vim/emacs getting these injuries. Makes sense as well right? Just like "take a walk and don't sit in the same place" but for your fingers
I don't know about carpel tunnel, but the reason I became interested in Vim/Emacs was due to RSI caused by using a mouse. This was my first job, doing shudders Java-EE (7) web development (no live re-loading, tons of clicking in IDE, manually reloading web-page etc, crappy windows touch-pad etc).
Started learning Rails, drank the Kool-Aid, switched to VIM. I don't use VIM for development at my day-job, mostly just key-bindings in Intellij/VS Code, however, the amount of time saved has been worth the effort, and no RSI (also thankfully am able to use the fantastic track-pad on mac and a trackball for anything else).
Lately I've been feeling the pull to learn Emacs after learning about ORG-Mode and the extensibility of the software... unfortunately, the time investment here is likely to have no real benefit in my (current) work as a Java dev. Sigh, time to browse the who's hiring thread.
Using Vim has helped my finger/wrist/arm/shoulder/neck pain and soreness, but you're on to something in that the real problem is probably more repetitive motions than any specific motions.
But Vim (and emacs) solves the repetitive motion problem by providing several means of readily repeating commands.
Most people seem to both type and use their mouse much more slowly than I do. And they also don't often have to (or want to), e.g. cleanup thousands of rows in an Excel worksheet, or have to repeat some kind of action in an app or web app dozens of times.
But I hate using my mouse generally. There are very few times where I want to use a mouse and having to use one, instead of being able to use the keyboard, is endlessly frustrating.
Thankfully, there are several great 'vi-style' browser extensions and there's even [Vimac](https://vimacapp.com/) for MacOS, tho I haven't tried the latter yet.
Maybe that's a bit like saying that running shoes are harmful because people with running shoes sustain running-related injuries more often than the average person, who in reality just doesn't run as much.
Mileage may vary depending on language support, but vim does have a go to definition feature[1][2]. I believe there is also out box error checking for some languages, and if that is not enough for you (and at the risk of offending a large number of vim purists), there is a fantastic plugin called ALE[3] that will likely provide you with what you want.
If you don't like vim for that you can point to another executable by setting gitconfig core.editor to an executable command which starts an editor of your choice. Mine points to Notepad++ (Windows box with msysgit installed).
text objects are a big reason for the satisfaction for me. I spend a fair amount of time moving code around and I like being able to say "delete everything in this indentation level and copy it" in 3 keystrokes. It's pretty sweet when you're use to it and you have it customized to do what you want (which takes time and isn't for everyone).
I honestly don't know how vim deals with unsaved changes upon shutdown and don't use it enough to look that up, so that's why I'll first exit.
As to why shutdown: cultural thing in the end. I was raised with the idea that wasting is bad (and objectively speaking it's very hard to argue with that) so if I don't need the machine running after I'm done with it, I just can't stand the idea of the thing using energy literally for nothing.
Depends on how you configure your swap, backup and undo files. You can have all the extremes from "everything is lost" to "everything is saved" if you suddenly kill the vim process.
This page is well at the bottom of the first results page, and vim tells you how to exit it now when you try things like ctrl+c. I don't think anyone is in danger.
https://i.imgur.com/b6dqBiV.png
>This page is well at the bottom of the first results page
It's at the bottom now, yes, but if this (and copycats) takes off, it won't be. I've seen cases where the search results get so dominated by oh-so-clever parodies that are mixed in with legit answers that you can't tell which is which.
>vim tells you how to exit it now when you try things like ctrl+c.
Which is great, if that version of vim universally replaced all the others, and every newbie was aware of ctrl-C.
For context: in 2011, I tried the project Open Hatch, specifically designed for newbies, and if you followed their tutorial instructions, you could get dumped into a vim terminal with no idea how to get out.
>I don't think anyone is in danger.
With respect, I'd suggest updating your criteria for making this judgment.
Look at it this way: maybe this show of insanity could cause further frustration and ideally help newcomers realize that avoiding vim altogether can be preferable for their future.
Oh dear. What are the chances this will eventually rank fairly highly on search engines - this is going to ruin the soul of the unsuspecting people who end up thinking that this is not satirical advice.
Better they ruin their own soul than inflict upon others is the way to look at that.
But then, what type of people don't RTFM besides the whole generation that treat google as their manual and when the internets down, so is there `knowledge` /s.
To clarify, if someone gets stuck in 'vim' when debugging an issue and searches the web for "how to exit vim" and ends up on the document linked in the OP ... your advice is "stick with Notepad"?
As a senior dev, I wanted to pat myself on the back and say
:q
But then I realized that the senior dev way is more like:
1. Look it up on Stack Overflow.
2. Send the Stack Oveflow to the intern and tell intern to do it.
3. Reject the PR because it lacks unit tests.
4. Reject the PR because it didn't account for an obscure case that product usually is concerned about.
5. Reject the PR because it there's a simpler way to do it.
6. Pair program with the intern because they're having trouble.
7. Realize that tests are a bit overkill, the obscure case can't happen, and the complexity is because of trying to make it testable and handling the obscure case.
8. Merge a PR that looks suspiciously like what the intern originally submitted.
9. When QA rejects, send back to QA asking for steps to reproduce (har har).
10. When QA sends back steps to reproduce, send back saying you can't reproduce (har har).
11. Sit with QA and see that the bug exists, because they doing something you didn't think of.
12. Fix the bug, merge the code.
13. When the manager asks you to, create the story in Pivotal and push it through all the states (everything so far happened in Slack).
14. Years later, come across the same problem at a different company, and notice someone `:q` in one of the side comments on Stack Overflow, which was there the last time you looked, you didn't notice it.
Next you'll be telling people to use SIGHUP instead of SIGKILL. Or to use the PID. Or to get VIM to substitute its own PID into the ex command using getpid().
I distinctly remember being a teenager and trying vim. Being entirely confused I wanted to exit and when I realized I couldn't I panicked a bit and started smashing keys. Eventually I gave up and forced a reboot with the power button. Based on my extensive experience with Windows I was confident it was hung in a bad state.
I came into this with a sense of "oh not again" and came out surprisingly happy. TIL that ZZ, ZQ exist and that a disown command exist on the command line.
Also my preferred method from the list is the timeout, it would be nice to have counter in a corner of the vim window to know how much time is left though.
I was on a remote system and remember I couldn't exit vi. What did I do? Well, I opened a second ssh session, looked up the process id with ps and killed it.
This is so many decades ago ... like the very beginning of my curiosity when it comes to IT basically. Thinking back to it, I wonder how I was able to use ssh and tools like grep, ps and kill but did not know how to operate basic vi ...
>Thinking back to it, I wonder how I was able to use ssh and tools like grep, ps and kill but did not know how to operate basic vi ...
This has become a recurring thing for me to the point where I sometimes feel like I'm not as intelligent as I used to be. I'll need to look at requirements around older existing code, so I use git blame to see the commit history. It occasionally leads to me to some older code that I had written, and sometimes I marvel at how I was able to figure out or troubleshoot the issue.
One of the earliest examples in my professional career is using Threads. I had an academic understanding of threads. My practical knowledge around them was dubious at best. With the help of Stack Overflow and lots of web searching, I cobbled together a thread manager that can spawn separate threads for asynchronous web requests and kill a web request after X amount of time. I even made sure that error handling redirected gracefully should one of those threads get killed. That code (with no changes to the core functionality) still exists to this day.
I did similar with early desktop Linux. vim opened up in one of the ttys, and I couldn't figure out how to close it, so I hopped to another tty and killed it.
This is as good of a place as any to mention that I built https://howtoquitvim.com a while back if you need a less-sadistic reminder for how to exit Everybody's Favorite Text Editor.
BRS, that old classic Big Red Switch, kills all known operating systems and proc's, dead in their tracks.
Me, It's usually :wq, or sometimes :q! or more than likely ZZ - which can be done with shift zz or if you truly want to do it with just one finger, capslock then zz.
That is because it is easier to teach as x you will associate with exit, though wq is write quite, but more so if you just want to save without exit you logically understand to just use w and from that you start to think - could I do :q, why yes you can if nothing changed and if so it will tell you.
But stressing how people exit vi is like stressing about people's fashion, just not worth it. If anything, have a private laugh at them to yourself and use that to remove other stress as more than enough stress in life, more so IT without seeking it out.
Ctrl-o moves from INSERT mode to COMMAND mode for one command and so it still works in "easy" mode. I notice that "easy" mode was one of the things that the Nvim guys removed.
Bold claim, and how would you know? What if there is a network partition preventing you from getting the message that exiting vi failed and Chuck Norris?
Interestingly, deleting the vim executable won't exit, because Unix has the "funny" habit of keeping a file handle alive as long as it's referenced by a process.
Really cool way to mess with some noobs.
After I invent time travel I'm going to mail my 30-years-ago self a T-shirt that says "Colon Q Bang" on the front and "You're Welcome" on the back. It will save myself much anguish.
There is a step somewhere in there where we waste 30 minutes playing "agile poker" and arguing about the number of story points required to close vim.
The whole thing is followed up with a two hour retrospective where we pat ourselves on the back for increasing velocity (due to assigning story points to closing vim).
Bonus points if you then are asked to map that back to actual hours so we can estimate completely unrelated future tasks while simultaneously remembering that we don't estimate in hours.
You forgot the conversation on the way back from the retrospective about how velocity is a bullshit indicator of actual productivity and we aren't doing agile correctly at this company.
It saddens me to say, but this is so familiar. Especially working in a big corporate company where they hire scrum masters who just follow the scrum guide.
Scrum has a built in self destruct method - the retrospective. With a little maneuvering, the team should be able to remove most of the annoying things about scrum by using the retrospective. Obviously you can't go scorched earth and drop all the annoying bits at once. But, if scrum is really being followed (I know this is also part of the problem), the retro should allow the team to change the process over time.
I found that, being a special time set aside specifically for team arguments about how many angels can dance on the head of a pin, the retrospective tends to produce a much more literal version of self-destruction.
I showed up long after they implemented it, so I'm not sure how they got there, but the most well-functioning Scrum team I ever participated in had effectively designated the nominal Scrum Master as a BDFL. The retrospective then became a shorter sort of town hall meeting where everyone aired their opinions, but, since we had a BDFL, we had no need to burn energy on consensus-building. Sadly, things quickly went to hell after she left and the team reverted to a more traditional consensus-oriented approach.
I would not call it self destruct, rather reconstruct or adjust. If the way the team uses Scrum isn't effective, then the retrospective can be used to explore issues and adjust the way of working.
This obviously only works when your scrum master is willing to take feedback on scrum processes. Which, with most scrum masters is not the case, you’re essentially telling them they’re doing a bad job, and it usually hurts their ego.
I honestly haven't met many scrum masters who don't just preach the scrum guide. Even if the team is struggling with the way we do Agile, the scrum master will just continue to force the scrum guide onto the team.
What I currently see is that our scrum master has sold the business on the agile way, so if a developer complains about it, there's something wrong with the developer. It's probably just a bad scrum master, but I've met multiple of those.
Disagree: the team owns the retrospective, not the Scrum master. If team members aren't happy with what the Scrum master is doing, that should be addressed in the retrospective.
And this is coming from your own personal experience? I've never been in a scrum team where we as developers had any say in what the scrum master was doing. The most we could do was retrospectives with other developers, and try to improve there. However that's rarely enough to make a business work.
Exactly, and those scrum-masters are usually good at talking and getting the business on their sides. There's literally no way to change those processes without making yourself look bad.
Can we also have some sort of a scrumish gathering, ASAP, to declare the correct use of the word "definition", because sometimes it seems we use this word arbitrarily.
As an Emacs user I just realized to my horror that I know the command(s) to exit vim but not the one(s) to exit Emacs. I can only tell you it begins with C-x. (Of course, my left hand knows.)
I once found a system where a third party vendor installed vim as root with suid permissions.
I've had a few days of fun before I finally decided to clue the sysadmin about it.
What about querying how much ram you have and then pasting the letter 'q' that many times plus one into the buffer?
Edit: perhaps to speed it up: start with a single 'q', selecting all, yank, and paste. Just script it to repeat until exit happens. No ram query needed.
As I sit here, vim running for several months inside an nvim terminal inside a tmux window inside an iterm tab inside mac os x, I think the real question is, why exit vim yourself when you can Inception vim's creator to do it for you?
That, as many people know, is actually how vim finally became threaded, and I'm sure it could be used to make a code change that exits vim automatically. Then you only have the task of modifying your vim executable in memory as well as on disk, which is so trivial that I leave it as an exercise to the reader.
WARNING: Learning to exit Vim is the number one gateway drug to perpetual configuration of dotfiles and plugins. The truth is that you can never exit Vim. NEVER!
Don't run this, it could break your computer.
:!echo b | sudo tee -a /proc/sysrq-trigger
Why would that break my computer?
Doesn't that just force a reboot without unmounting disks, or about the same thing that would happen if you pull the power cord (but probably safer, since anything in a hard drive write cache (or in the middle of being written to an SSD) will still be written)
Didn't see a mention of a very fast way of exiting Vim, so sharing:
'The iTerm way': map cmd-l to send a hex code '0x6A 0x6B 0x3A 0x71 0x0D' (translates to jk:q<enter>, where jk is my Vim binding to get out of insert mode)
For me, just like any other touch typer, left thumb is always on cmd and right ring finger is always on 'l' key, so this arrangement takes least amount of time for me to quit Vim.
This is a well studied problem from the days of Turing. Named slightly differently as the Halting Problem, the question of whether Vim will stop for a given arbitrary input has been proven by Turing [https://en.m.wikipedia.org/wiki/Halting_problem] to be unsolvable.
The funniest one is the "experienced product manager way" IMO. I've seen plenty of those "experienced project managers" work, and the description is spot on. It's amazing that such impediment to productivity is even tolerated, let alone paid handsome amounts of money for. All while the company _thinks_ they're getting better productivity.
yy - yank
dd - delete and yank
O - insert line above
o - insert line below
GG - go to bottom of file
gg - go to top of file
Navigation keys
== - auto indent code block
v - visual mode
:%s/find/replace/g
:set paste
:set number
:set nonumber
:q - quit
:-p
Fun read! My next bash exercise will be to try and understand some of these commands, quite a feat! greping the ps output would work with any program, right ? That was pretty cool. Killing it from emacs was def a good laugh !
They should add the script kiddie way: `sudo rm -rf /` ^^
In fact "pkill init" or "kill 0" (each with sudo/root privileges executed) will most likely kill all processes and is some kind of process equivalent to delete all files ;-)
If you use `kill -9` to exit vim, you might find your terminal in a weird state, because they are most likely using the `atexit` function to reset your termios settings to normal, but that doesn't happen if you `kill -9` it.
You could send a PR with an “Acceptance way”.
Also there’s “Radical acceptance way”: kill every other process, although I’m from mobile and too lazy to work out an exact shell command for that
As a vim noob, I needed to look it up [0]. ZZ saves the current file if modified and closes it. ZQ closes it without saving. Thank you, that will save me a few seconds per year.
Why the French way? I don't get it and I am very curious :-)
Yes, but it’s never been just about startups or business. It’s always been any topic of interest to hacker types which includes startups and business, but also technology, programming, tools, peoples projects and even sometimes satire of such.
Oh look, it’s only been 10 minutes since somebody complained that a post shouldn’t be on HN or that a topic is over represented and what a bubble HN is!
You have just been arrested on suspicion of wrong-think. If this audience loves Vim and you don't, you have landed on the wrong planet and committed a thought-crime.
You don't have to say anything because the HN jury has already found you guilty on multiple accounts of high treason with a thought-crime and the maximum penalty is a lifetime ban.
Vim is still VERY relevant. Lot's of us prefer its keyboard driven interface and it runs everywhere so if you do learn it it's something you can always have with you.
It's not like VS Code has much in the way of functionality that's not available to Vim/Nvim users via VSCode's extensions or LSP servers.
From perspective of ASCII-only application, vim interface isn't actually bad, it just lacks discoverability. There is also a real cost to making tool beginner-friendly and it often makes sense to optimize for advanced users instead.
Once you learn the tool, discoverability wastes screen space and user focus. It's like training wheels, at some point you want them off or they slow you down. I'm not a vim user, I just appreciate the UI trade-offs made by its devs.
At that point, you should be able to hide the parts of its interface that you no longer need. Defaulting to an optimized, non-discoverable setup from the start is simply a bad idea.
Somehow I discovered that 'vi' was the way to edit things, but I didn't know how to exit, so trial and error led me to pressing control and z at the same time. Bingo! The shell is back.
After some days of building up background suspended vi instances, the system administrator came in and gave me a few pointers.