Vim is a great text editor - try it(joelhughes.co.uk)
joelhughes.co.uk
Vim is a great text editor - try it
http://www.joelhughes.co.uk/blog/2009/10/vim-is-a-great-text-editor/
15 comments
I have put together some suggestions/hints for vi users using vim a while back that might be helpful as well.
http://geocar.sdf1.org/vim-hints.html
http://geocar.sdf1.org/vim-hints.html
Pet peeve:
I can.
It requires that you put knowledge on the X-axis, and time on the Y-axis, which is completely at odds with the usual way of doing things.
Like many idioms you have to read this as meaning one thing even though it says another. You have to read this as "it takes a long time," even though that's not what it says.
Language - I don't know how it works.
And sometimes it doesn't.
</rant>
There may be a steep learning curve ...
I can.
It requires that you put knowledge on the X-axis, and time on the Y-axis, which is completely at odds with the usual way of doing things.
Like many idioms you have to read this as meaning one thing even though it says another. You have to read this as "it takes a long time," even though that's not what it says.
Language - I don't know how it works.
And sometimes it doesn't.
</rant>
Look, it's really not that tough. Here's what you need to treat vim as a text editor with syntax highlighting:
Emacs can be treated similiarly: C = control M = "meta", usually the alt or option key. You can use escape if you want.
esc (escape) = go to the default mode
i (insert) = when you want to make changes to the document
esc + : (escape, colon) = think of this as control + whatever
:w = (w)rite - save your file
:q = (q)uit - quit vim
:wq = (w)rite, then (q)uit
:q! = (q)uit!, discarding any changes
Emacs can be treated similiarly: C = control M = "meta", usually the alt or option key. You can use escape if you want.
C-x C-f = control x (do something) + control f (find file) - open a file
C-x C-s = save a file
C-x C-c = quit
C-k = (k)ill - this is similar to cut
C-y = yank - this is similar to paste
M-x cua-mode
(btw, m-x means "run this function")
You're replying to the wrong person - vim is my primary editor. I'm ranting about the stupidity of the phrase "Steep learning curve."
heh, I guess I misread what it was you were ranting about; I took it to mean that you hate any sort of learning curve when it comes to editors. Thanks for clarifying!
You left out hjkl and C-bnpf, the cursor. And / and C-s, search. These are the only things I know in vi but it makes it barely usable for config.
If you're using vi/vim for real programming, you'll want to know about tag searching as well - it's one of the better ways to deal with multi-file source code. In both nvi and vim, control-] jumps to the tag under the cursor, and control-t pops back to the previous context. (You'll need to run a program such as ctags on the source to create the tag index first.)
I think it means that there is a lot of stuff you need to learn all at once, upfront, before you can really use vi effectively. It's in contrast to being able to just learn a few basics and pick it up gradually. The steepness of the learning curve doesn't have anything to do with how long it takes overall.
The phrase originally meant easy to learn with diminishing returns after a certain point, for exactly the reasons you suggest. However, the phrase "steep" implies something hard to do, so the phrase gradually lost that meaning and gained the opposite. I fear the same fate for the word "nonplussed." "Unique" is already half dead and is migrating to a synonym for "unusual." The subjunctive tense is huddled in its bunker somewhere, wishing it were more popular. The pluperfect feels secure now, but its day will come. Its day will come, friend.
The phrase "steep learning curve" means hard to learn, or with a lot of stuff to learn, not anything to do with time (except as it takes more time to learn more, I guess). The graph is of usefulness vs amount learned.
I always thought that productivity was on the X-axis and the cumulative summation of effort was the Y-axis, and the steepness of the curve was about the large size of the derivative. But now that I write it all out, that is probably too much math to attribute to a common phrase.
I've never associated a "steep learning curve" with the time it takes to learn, more that there is quite a bit of knowledge that is needed to have a baseline proficiency in it. I suppose that would put Usefulness/proficiency on the Y-axis and knowledge on the X.
Nope, that's still the wrong way round. If "usefulness" is Y and "knowledge" is X, and you needs lots of knowledge before it's useful, then the curve is shallow.
I see it something like: http://www.wolframalpha.com/input/?i=Plot[%28Sqrt[Pi]+Erf[3x...]. At first, you can use it and get something done, but it isn't useful. As you learn more, it becomes slightly more useful, but not much, until it hits a point where you finally understand the interface, and can use the features to their complete intent.
Having thought this through a little more, it seems more like bumps. For example, you can't do anything with Vim until you learn basic motion and insertion. That a bump. Then, you learn how to use the more complex motions, and get another bump. With something that has a steep learning curve it is done in bumps, rather than being smooth, because partial knowledge doesn't help any. If you think about it, if you only know the j and r commands in vim, you're not going to be doing anything at all, you're going to need to know at least hjkli before you can even use it.
Having thought this through a little more, it seems more like bumps. For example, you can't do anything with Vim until you learn basic motion and insertion. That a bump. Then, you learn how to use the more complex motions, and get another bump. With something that has a steep learning curve it is done in bumps, rather than being smooth, because partial knowledge doesn't help any. If you think about it, if you only know the j and r commands in vim, you're not going to be doing anything at all, you're going to need to know at least hjkli before you can even use it.
I've decided that "steep learning curve" doesn't have to do with mathematical graphs at all. Saying something has a steep learning curve is the same as saying there is a barrier to entry. That barrier is knowledge, and a steep path over that barrier indicates a lot of of basic knowledge is necessary to get past the barrier.
I don't think "takes a long time" is necessarily right - learning vim in an adjustment, you can make that adjustment over a long or short period. Also, that adjustment will be easier if you are looking forward to the advantages it can bring.
It ought to be the contamination of the mental images of a graph and a steep hill (which is hard to climb).
Neither a pedagogical nor an intuitive analogy -- but fun!
Since I don't write parsers for natural languages, I like that kind of expressions more than they irritate me.
vi fans might think that is related to me prefering emacs... :-)
Edit: Grammar, spelling. Sigh.
Neither a pedagogical nor an intuitive analogy -- but fun!
Since I don't write parsers for natural languages, I like that kind of expressions more than they irritate me.
vi fans might think that is related to me prefering emacs... :-)
Edit: Grammar, spelling. Sigh.
Good lord!
The main reason to learn vi is that it is installed by default on so many systems, including most ancient Unixes.
When your task is to edit a config file and you don't have time/permissions to install your editor of preference.... vi is the only choice.
Emacs and others may not be present on a system when you really need it.
A basic competence in vi is essential if you're going to deal with Unix. Even if you prefer Emacs (like me) or other myriad tools.
The main reason to learn vi is that it is installed by default on so many systems, including most ancient Unixes.
When your task is to edit a config file and you don't have time/permissions to install your editor of preference.... vi is the only choice.
Emacs and others may not be present on a system when you really need it.
A basic competence in vi is essential if you're going to deal with Unix. Even if you prefer Emacs (like me) or other myriad tools.
Sometimes, if you're really screwed, you may not be able to mount the partition with vi. ed is almost always on Unix, though. (Knowing how to open a file, find and change a few lines, and resave is probably good enough for emergency situations.)
Also, it's worth learning ed because the ex prompt in vim shares most of its functionality, and because sooner or later you'll realize how lucky you are that you don't have to work on a teletype. :)
Also, it's worth learning ed because the ex prompt in vim shares most of its functionality, and because sooner or later you'll realize how lucky you are that you don't have to work on a teletype. :)
Ed is fun to use, and learning it makes you better at vi.
Your comment made me smile. I had a thought of a fictional programmer so editor-centric, they decide on their programming language based on which one will help them improve their skills at vi. (Which is a misinterpretation of your comment. vi has roots in ed, so some of the cool esoteric stuff is invoked in the same way.)
From what I've seen of vi (mainly as a result of editing files directly on a server via ssh), it seems like an efficient text editor, undoubtedly. But what about if you're constantly bouncing between different files in a project? Like a Rails project, for example, with its many different files for models, views and controllers?
I.e. how good is it at handling projects, as opposed to just files?
I.e. how good is it at handling projects, as opposed to just files?
[deleted]
There are a lot of ways to use Vim on multiple-files/projects, and the documentation is probably the best place to start.
You can also plug it into Eclipse via eclim http://eclim.sourceforge.net/
You can also plug it into Eclipse via eclim http://eclim.sourceforge.net/
There are two plugins which have helped me enormously when dealing with large projects: bufexplorer and nerdtree. Check them out, seriously.
It is good, especially with rails.vim and NERDtree installed. fuzzy_file_finder is super useful as well, can't recommend it enough.
Honestly, my current solution to that is to get my current directory correct when I start (:cd ~/Programming/project) and then just :e app/controllers/users_controller.rb when I need a file. Tab completion makes it fast enough that it's not worth optimizing faster.
Most vi users I know use a combination of gnu screen and bash job control to accomplish this sort of thing.
[deleted]
i use a file that looks like this:
" session.vim
tabe file1
tabe file2
tabe file3
...
This is the top story on hacker news?
I am sick to death of the editor wars and editor advocacy, I wish people would just stop. I bet most hackers have made their editing decisions long ago and are content with their choices.
Having said that, I would like to add something positive to the discussion. I think whichever editor you choose, you should learn to move the cursor around without using the arrow keys. There is considerable value in keeping your hands on home row. Every time you reach for the arrow keys you add latency to your workflow. It adds up.
Having said that, I would like to add something positive to the discussion. I think whichever editor you choose, you should learn to move the cursor around without using the arrow keys. There is considerable value in keeping your hands on home row. Every time you reach for the arrow keys you add latency to your workflow. It adds up.
> I bet most hackers have made their editing decisions long ago and are content with their choices.
I think you're completely ignoring the next generation of hackers, which is unfortunate. I've been working on getting past vim's learning curve for over a year, on and off. True, this submission sucks, but it lead me to find this: http://www.viemu.com/a-why-vi-vim.html, which is pretty informative for a beginner.
I think you're completely ignoring the next generation of hackers, which is unfortunate. I've been working on getting past vim's learning curve for over a year, on and off. True, this submission sucks, but it lead me to find this: http://www.viemu.com/a-why-vi-vim.html, which is pretty informative for a beginner.
I like reading things about various editors now and then, and it certainly serves an educational purpose.
However, this does not require the spamming of "editor" advocacy posts (where "editor" has meant "vim") recently.
However, this does not require the spamming of "editor" advocacy posts (where "editor" has meant "vim") recently.
That goes triple for switching between the keyboard and mouse, unless you have a specific workflow that involves the mouse and the keyboard at the same time (as is common with Photoshop, Autocad, etc.).
I've used Visual Studio and variants for 7 years professionally. I've had some familiarity with vim for the the past 3 years or so, but it was only in the last year that I have come to really enjoy using vim. As tiring as these articles may seem, they need to keep coming in a slow, but steady, stream so that others can find out what they have been missing.
[deleted]
Until enough people either flag it or submit other posts with more substance, yes.
In the mean time, maybe the discussion will justify its continued existence on the front page.
In the mean time, maybe the discussion will justify its continued existence on the front page.
Hackers like/use tools like Vim?
That's a dumb reason to vote up an article. If I submitted the man page of vim, would you upvote it? The man page is actually more useful than this blog post.
It's not about the subject, it's about the content.
It's not about the subject, it's about the content.
Right, voting up articles because you like them means that the front page will tend to get clogged with "woo $thing, vote this up if you like $thing too" type articles, which are almost always very shallow AND encourage other such banality.
There are still interesting discussions to be had about multiple-decade-old text editors, but this is not one of them.
There are still interesting discussions to be had about multiple-decade-old text editors, but this is not one of them.
Today I learned that Vim began on the Amiga.
http://cd.textfiles.com/fredfish/v1.6/FF_Disks/571-600/FF_59...
http://cd.textfiles.com/fredfish/v1.6/FF_Disks/571-600/FF_59...
The Amiga was the source of many great things. It also had CygnusEd which gets cited up to this day as inspiration for TextMate and others.
http://texteditors.org/cgi-bin/wiki.pl?CygnusEd
http://texteditors.org/cgi-bin/wiki.pl?CygnusEd
Short article, but voted up simply to voice my love for Vim.
It took me a long time to finally get comfortable with Vim. I would load it up every few weeks, learn a couple of commands or things like using split windows and then get frustrated/held up enough that I would go back to Textmate. After going through the process for a good few months, I then somehow managed to make it through a day without getting frustrated once. Then on the second day I literally felt like I was flying through my code. TBH I have never felt this productive in an editor before.
I would constantly read people saying that watching someone in Vim is like a work of art and never quite understood what they meant. But now I do. The speed at which I can navigate through a file, move text around, move around my project. Even simply never having to move my hands away from the home row makes me feel more focused on what I'm currently working on.
It took me a long time to finally get comfortable with Vim. I would load it up every few weeks, learn a couple of commands or things like using split windows and then get frustrated/held up enough that I would go back to Textmate. After going through the process for a good few months, I then somehow managed to make it through a day without getting frustrated once. Then on the second day I literally felt like I was flying through my code. TBH I have never felt this productive in an editor before.
I would constantly read people saying that watching someone in Vim is like a work of art and never quite understood what they meant. But now I do. The speed at which I can navigate through a file, move text around, move around my project. Even simply never having to move my hands away from the home row makes me feel more focused on what I'm currently working on.
> voted up simply to voice my love for Vim.
Please do not do this. It leads to really banal "vote up if you like _ too" posts on the front page.
I think a lot of people find vi unpleasant because it so unapologetically makes the trade-off of having dozens of (composable) single-character commands you have to memorize upfront, rather than a more conventional interface whose advanced features you can gradually learn. You can't really get an accurate impression of vi's strengths until you've already committed to memorizing a lot of commands - the terseness itself is a major feature in the long run. (Emacs is similar in this regard, but with very different trade-offs.)
For most programs, this trade-off is probably hard to justify, but for something that one spends a lot of time working with directly (such as a structurally-aware text editor, photoshop, autocad, etc.) it's probably reasonable.
Please do not do this. It leads to really banal "vote up if you like _ too" posts on the front page.
I think a lot of people find vi unpleasant because it so unapologetically makes the trade-off of having dozens of (composable) single-character commands you have to memorize upfront, rather than a more conventional interface whose advanced features you can gradually learn. You can't really get an accurate impression of vi's strengths until you've already committed to memorizing a lot of commands - the terseness itself is a major feature in the long run. (Emacs is similar in this regard, but with very different trade-offs.)
For most programs, this trade-off is probably hard to justify, but for something that one spends a lot of time working with directly (such as a structurally-aware text editor, photoshop, autocad, etc.) it's probably reasonable.
I'm going through that process now. It really is a culture difference when you've been using Windows, or other GUI apps in linux, for a long time. The links in the original link did help. This http://jmcpherson.org/editing.html is useful for me at the moment.
I'll sadly admit that for most quick file editing I still use pico/nano (which is installed on most every system that I've touched in the past 3-5 years). I used emacs around 1998, but at the time it was too big I felt and had too much power. vi was just damn confusing. When I saw people using it, it looked amazing, but I could just never get the handle on it.
When I'm editing big files/coding I use Cyberduck to SSH/SCP files over to TextMate, which works well most of the time. The only time it doesn't work is when I need to sudo edit that file, because Cyberduck can't sudo.
When I'm editing big files/coding I use Cyberduck to SSH/SCP files over to TextMate, which works well most of the time. The only time it doesn't work is when I need to sudo edit that file, because Cyberduck can't sudo.
For those of you who use Netbeans there is jVi ( http://jvi.sourceforge.net/ ) a fairly faithful Vi emulator.
Also, Komodo Edit ( http://www.activestate.com/komodo_edit/ ) is a modern free, multi-platform editor which has nice Vi support.
Also, Komodo Edit ( http://www.activestate.com/komodo_edit/ ) is a modern free, multi-platform editor which has nice Vi support.
What I'm trying to figure out is whether vi/emacs, and the Unix command line, is actually still a relevant way to do development.
You see, cults that are divorced from empiricism _do_ exist in CS; I'm sure of this. But I'm not sure of whether people who feel such strong love for the command line belong to one or not.
As a pure text editor, Vim seems really nice. However, once I start wanting to do what I take for granted as fairly basic things, I want the mouse and graphics more and more. For example, say I just want to have program output, a couple of code listings, and a visual debugger all on the screen at once across multiple monitors with integration between them. People swear that the Unix prompt is better anyway. However, they all seem to be programmers whose careers peaked in the 70s or 80s too! I'm a Unix neophyte but my first impression in trying to do C programming in vi is that without all the comforts that something like Visual Studio gives me, it just sucks. I'd love to be proven wrong actually, but the people on the other side of the argument also seem to be dinosaurs (albeit genius dinosaurs) who don't even think that trace-through debugging is a good thing. Heck, even Linus lost that fight.
Vi-style editing inside a modern IDE like Eclipse or Visual Studio does seem interesting though.
You see, cults that are divorced from empiricism _do_ exist in CS; I'm sure of this. But I'm not sure of whether people who feel such strong love for the command line belong to one or not.
As a pure text editor, Vim seems really nice. However, once I start wanting to do what I take for granted as fairly basic things, I want the mouse and graphics more and more. For example, say I just want to have program output, a couple of code listings, and a visual debugger all on the screen at once across multiple monitors with integration between them. People swear that the Unix prompt is better anyway. However, they all seem to be programmers whose careers peaked in the 70s or 80s too! I'm a Unix neophyte but my first impression in trying to do C programming in vi is that without all the comforts that something like Visual Studio gives me, it just sucks. I'd love to be proven wrong actually, but the people on the other side of the argument also seem to be dinosaurs (albeit genius dinosaurs) who don't even think that trace-through debugging is a good thing. Heck, even Linus lost that fight.
Vi-style editing inside a modern IDE like Eclipse or Visual Studio does seem interesting though.
The power of the command line and editors like vim and Emacs is only apparent after spending a lot of time with them. It also requires a methodical use of documentation.
C programming in vim might seem masochistic compared to Visual Studio. I'd suggest that Emacs offers a richer set of features when building software in C, complete with autocompletion, SCM integration, and build commands.
You can also use Emacs (or just GNU Screen) to have split views of source code and program output and the debugger (gdb) in one window. The real advantage of the command line environment is the ability to create new tools. When you're in Visual Studio or Eclipse it's a much more formal and involved process to create a custom command or automate something and integrate it with your workflow. With the CLI you can just throw together the tool you have in mind in whatever language is most suitable, and integration is not an issue because the shell (hosted in Emacs or not) is an integral part of your "IDE" at this point.
Compared to tools like Visual Studio and Eclipse, the trek is longer but the peak is higher with Emacs and the CLI.
C programming in vim might seem masochistic compared to Visual Studio. I'd suggest that Emacs offers a richer set of features when building software in C, complete with autocompletion, SCM integration, and build commands.
You can also use Emacs (or just GNU Screen) to have split views of source code and program output and the debugger (gdb) in one window. The real advantage of the command line environment is the ability to create new tools. When you're in Visual Studio or Eclipse it's a much more formal and involved process to create a custom command or automate something and integrate it with your workflow. With the CLI you can just throw together the tool you have in mind in whatever language is most suitable, and integration is not an issue because the shell (hosted in Emacs or not) is an integral part of your "IDE" at this point.
Compared to tools like Visual Studio and Eclipse, the trek is longer but the peak is higher with Emacs and the CLI.
> all the comforts that something like Visual Studio gives
What are these, anyhow? Whenever I've used Visual Studio or Eclipse it's felt like a burden.
What are these, anyhow? Whenever I've used Visual Studio or Eclipse it's felt like a burden.
> What are these, anyhow?
Integrated debugging. (I know gdb is incredibly powerful, but it seems too much to have to reprogram my brain for yet another editor within an editor.) Errors and warnings appearing while I type. Ctrl+click to go to source for any function I'm viewing. Variable and function auto-complete. Integrated documentation for functions that appears as I am typing. Quick and easy navigation of a file hierarchy. (I know vi and emacs allow this but it requires a level of mastery and key memorization for benefits that seem far from clear to me.) Managing project settings. Refactoring.
For someone that has achieved mastery over Unix over many many years, these things either seem unnecessary or they have a substitute (that's perhaps even better). However, I guess I'm wondering if there is a group of people who aren't old programmers from the 80s who started with something like Visual Studio or Eclipse, used it enough to achieve a level of mastery over programming that way (with a brain trained to use the mouse), and then after that found a gain switching to command-line type tools, that was worth the many many additional hours of brain re-training.
Integrated debugging. (I know gdb is incredibly powerful, but it seems too much to have to reprogram my brain for yet another editor within an editor.) Errors and warnings appearing while I type. Ctrl+click to go to source for any function I'm viewing. Variable and function auto-complete. Integrated documentation for functions that appears as I am typing. Quick and easy navigation of a file hierarchy. (I know vi and emacs allow this but it requires a level of mastery and key memorization for benefits that seem far from clear to me.) Managing project settings. Refactoring.
For someone that has achieved mastery over Unix over many many years, these things either seem unnecessary or they have a substitute (that's perhaps even better). However, I guess I'm wondering if there is a group of people who aren't old programmers from the 80s who started with something like Visual Studio or Eclipse, used it enough to achieve a level of mastery over programming that way (with a brain trained to use the mouse), and then after that found a gain switching to command-line type tools, that was worth the many many additional hours of brain re-training.
Also, emacs.
Could you flesh that out a little?
Dammit, emacs! :-) A good place to plug xkcd, I think: http://xkcd.com/378/
I tried it. I tried vi, vim, gvim.
I now use a number of editors and IDEs. Vim is not not of them. I launch it once in a while, just so I would not forget how it feels (and would not forget how to :wq). That's all.
As far as the holy flame war on editors, I do not have much to say about it, and will avoid reading much about it.
I now use a number of editors and IDEs. Vim is not not of them. I launch it once in a while, just so I would not forget how it feels (and would not forget how to :wq). That's all.
As far as the holy flame war on editors, I do not have much to say about it, and will avoid reading much about it.
Is it worth learning how to use vim (well) if I already feel fairly comfortable in another text editor? The author only touched on speed and how you're more "involved" with the code, which were vague enough that I was left unconvinced.
It's definitely worth learning enough to use, just in case your preferred editor isn't available. I tried it, but couldn't get used to switching modes, I kept messing up my file and having to backout and fix things; so I memorized a subset of vi that would let me get any editing done that I absolutely had to and went back to using emacs for regular use. Note that the default version of vi is not always vim, some systems use elvis or other vi clone, some of which have different advanced features and keybindings; for use when nothing else is available, concentrate on the basic vi commands.
Perhaps. I don't know what other editor you use, but if you use Unix with any regularity, I'd recommend learning either Emacs or vi.
I use both, but tend to use them in different situations. Major, multi-file editing in Emacs, but quick edits or work on other computers in vi.
More comparison: http://news.ycombinator.com/item?id=230990
I use both, but tend to use them in different situations. Major, multi-file editing in Emacs, but quick edits or work on other computers in vi.
More comparison: http://news.ycombinator.com/item?id=230990
Sure I dont mind reading an article on Vim (or even Emacs), but please, try to add something instead of linking to other resources.
Oh please, here we go again. Stop advocating your love for that 30 year-old piece of software. Please. Stop it. You don't hear ME expressing my love for Eclipse on a daily basis, now do you? Seems like you have some convincing to do?
Plus, I'm not buying it. If it's so great, why do you even have to market it? Wouldn't it just sell itself? But no. Instead we get these "VI is great" vs "Emacs is better" discussions every-f*cking-time. And I've had it. Just use your old, old, old piece of software, be happy about, and stop trying to convince me.
Plus, I'm not buying it. If it's so great, why do you even have to market it? Wouldn't it just sell itself? But no. Instead we get these "VI is great" vs "Emacs is better" discussions every-f*cking-time. And I've had it. Just use your old, old, old piece of software, be happy about, and stop trying to convince me.
If it's so great, why do you even have to market it?
That's kinda silly. That's like saying "why does Apple spend jillions of dollars marketing the iPhone if it's so great?" Some people genuinely don't know about [pick your editor], and some people like their tools so much, they like to tell you about them. Isn't that the whole point of blogs, anyway?
That's kinda silly. That's like saying "why does Apple spend jillions of dollars marketing the iPhone if it's so great?" Some people genuinely don't know about [pick your editor], and some people like their tools so much, they like to tell you about them. Isn't that the whole point of blogs, anyway?
> "why does Apple spend jillions of dollars marketing the iPhone if it's so great?"
Because it leads to massive profit. I don't think it's pure altruism motivated by a desire to give better user experiences.
Because it leads to massive profit. I don't think it's pure altruism motivated by a desire to give better user experiences.
It's not just about the money, though. How is free/open source supposed to gain traction, if not by people saying "hey, this is good!" If no one "markets" a piece of software, how you know about? How did _you_ find out about the tools you use?
Agreed, but I was just pointing out a clear non-sequitur in the parent post. People should use logic when making a point.
i, too, am a very happy long time (13+ years) vi/vim user. if you haven't ever used a powerful keyboard-only text editor such as vim or emacs, you simply have no idea what you've been missing.
quit being a curmudgeon. this is one happy human sharing something they love with others. if you don't want any of it, just keep moving. your negativity does not advance the human condition.
quit being a curmudgeon. this is one happy human sharing something they love with others. if you don't want any of it, just keep moving. your negativity does not advance the human condition.
Or is it that if you spend 13+ years with any tool, you get very intimate and familiar with it, learn to appreciate its strengths, and don't have an objective view anymore as to the weaknesses. (Especially weaknesses during the first year when you weren't a master.)
I guess to compare, you'd have to have used an IDE with GUI for 13 years too? I bet you'd be very effective that way too.
I guess to compare, you'd have to have used an IDE with GUI for 13 years too? I bet you'd be very effective that way too.
If you spend that long with a tool, you certainly push out and find the weaknesses
Why are you being so ageist? Old software is the stuff that's grizzled and survived all comers. It's the stuff that people like enough to drag along with them into the future porting to new architectures, operating systems, windowing systems as they go. Not because some company wants to push it but just because it really is that good.
If it's so great, why do you even have to market it? Wouldn't it just sell itself?
Countering this is a common meme in HN articles - that you can't just write some polished software in a room somewhere and expect people to beat a path to your door for it.
If it's so great, why do you even have to market it? Wouldn't it just sell itself?
Countering this is a common meme in HN articles - that you can't just write some polished software in a room somewhere and expect people to beat a path to your door for it.
I believe the reason it comes up so often is because the depth of the software. I'm just starting, but from what I have been told there is a ton of things to learn, and its hard to know where to go after the first tutorial or two.
Yes Vim was started a long time ago (1991), that means that it has had that bit longer to refine. Eclipse is great too, and people do say so. Add Vim to Eclipse and you can have the best of both.
Don't like it? Don't use it.
Others, who basically edit text for a living, like to explore their options.
You don't rant at every ad you see, do you?
Others, who basically edit text for a living, like to explore their options.
You don't rant at every ad you see, do you?
[deleted]
Ok, I would have expected to be downvoted. Dissent on VI vs Emacs is not tolerated among Computer Scientist (and I'm one myself).
Nope, I don't think the downvoting came from dissent, it came from you shitting on other people contributing helpful technical documentation while adding no value of your own.
* Why, oh why, do those nutheads use vi? http://www.viemu.com/a-why-vi-vim.html
* Graphical vi/vim cheatsheet & tutorial http://www.viemu.com/a_vi_vim_graphical_cheat_sheet_tutorial...