For years I enjoyed Borland products, they used Wordstar key bindings.
And then one day it stopped working. I simply had to use the mouse.
I was shocked.
It took me years to recover. I hated it.
Call me a masochist, a few years ago I tried Emacs, it was the only editor with syntax enlighting for Ruby at the time.
Except it was not working, or at least it was not working for me.
I had learned a little bit of lisp however, so it was not a total waste of time.
A few ago I was so frustrated with my editor (Notepad++), that I decided to give Vim a try.
Well... I am french. I can tell you that using Vim with a french keyboard is hell. That, plus copy/paste with the mouse working erratically (that is: more or less depending on the current "mode")... I quickly got frustrated again.
And then, boom, my netbook's hard drive goes back to his creator and I am forced to switch to my Linux netbook. No more Notepad++ there. I am back with SciTe.
Now my friends, may be you will understand it better when I will tell you a little secret I am sligthly ashamed of:
My project is mainly ONE big file, almost 12 000 lines of code, even the CSS that I used in in it.
No more buffers, no more windows, no more subdirectory to navigate.
Just one big file.
Heaven.
I wish I had seen the ligth before.
All I miss is a little post processor tool, with which I could define "sections" in my big file. Sections that it will dispatch into their own little files.
And when I will move to git, I will write it, and I will make it "bidirectortional", so that I can fetch back changed files, fetch them back into my BIG file that is.
A few years ago I was chatting with some fellow geeks, and, as often happens, we got on to ridiculing PHP developers.
Ha ha! Every PHP app is one big file! What losers. Yeah, we were having blast with these digs. But then I realized that, at least in some ways, this was an epic win. Have to go dig into some alien app? No worries; everything you need (or probably care about) is in the one big file. Need to deploy? FTP that one big file.
Seriously, maybe it's not as crazy as it seems.
The better approach might be for your editor to behave as if all code were one big file, when needed, and behave as if all code were nicely split out, when needed.
And have multiple files makes life easier when you're on a team and several people are touching different parts of an app.
But before rejecting something like this out of hand, consider what your needs really are, and if how you're doing things is really what's going to work best for you.
Editor where just TOO SLOW to handle big files (on DOS they often were limited to 64kb, if not less)
Please note that I love "modular code", hence the notion of "sections" in my big file.
To clarify: I love to edit one big file, but for other purposes I definitely need small ones.
What I am basically proposing is that it is easier to edit multiple files from within a single window/buffer. But there exist no editors that do that AFAIK
Not quite true though, but again it's speed related (and this is very apparent in C++ projects). It has benefits when compiling a changed file. The smaller your file and the fewer things you include, the faster you can compile it and link it with the other (unchanged) objects.
I can see how that would be useful, but I have a question. If you do edits in both windows, how do you save them? Do you just save in one window and reload the other?
In vim, when you have the same file open in different windows any changes immediately appear in the other window. They are the same buffer, there are just two windows to it.
You can see this by opening a file, and hitting "<Ctrl-W> <Ctrl-S>" to split the window. Do some editing and you'll see it in both places. ":ls" will show only one buffer. And if you have display of the buffer state visible, when you ":w" all the windows will update to say they were saved.
I wonder if some smart lawyers could team with some physical therapists to create some massive lawsuits- force companies to offer mouse-alternatives for all their programs or something. The law's done much worse.
-- And I think I once cleaned-up some code based on the "one big file" principle...
The "speed of thought" is essentially the limiting factor in most keyboard input presently.
A normal mouse move requires a lot more bits input to get the effect of several keystrokes and so a thought-controlled mouse would require "more thought" than keystroking requires.
But if you could get broad spectrum output - text, sound, pictures and video, a direct brain interface would be fabulous...
But remember, direct-brain output sounds great but the "high bandwidth outputs" we humans have now (our hands and mouths mostly), were "designed"/evolved as outputs and anything else will be "internal data" - not necessarily useful and quite possibly not what we'd chose to output. This could be overcome but I suspect this means direct brain output will not come a smoothly as one might expect (even with the immense progress of computers
As far as lawsuits go, if you started one now, it would change a lot of behavior even before it finished. And liability for past behavior still exists whatever the present situation is.
The man throws out an excellent plug in the article: vimcasts (http://vimcasts.org).
Drew Neil (the man who creates/narrates them) does an excellent job of explaining not only the basics of vim, but also the intricacies of it as well. I consider myself a fairly seasoned vim user, but even I picked up a few tricks from his vimcasts. Try them out.
I love VIM. It's my go to editor for everything. And as much as I love it I hate to admit that I was more productive using Eclipse when it came to a large-ish web project.
I tried using gVIM tabs, an buffers, and minibufexplorer, and Project, and ctags. Either I was doing it wrong or they just didn't want to work how I thought and worked.
So I'll lust after VIM and use it when I can, but I'll default to Eclipse when it comes time to work with a project set.
I'm running Ubuntu on my development machine, and I really enjoy VIM keybindings. I had a lot of trouble getting the key bindings to work in Eclipse, but jVi worked like a charm in NetBeans for me. (Needed a rich IDE for some Magento dev. Sometimes to make a 2-line change properly in the core involves making 3 dirs, 2 XML files, 1 php file. le sigh)
Try Eclim for your java work. It's a set of vim plugins which run and communicate with a headless Eclipse instance in the background. This allows you use Vim as your editor and pull many of Eclipse's fancy features forward.
For anyone interested I'd suggest to also look at FuzzyFinder. It does the same thing but is a little more advanced (real fuzzy search, also works on buffers, etc.):
vim is more of a text editor that emphasizes a minimum of keystrokes to do things efficiently. Emacs is a text editor that is leans more to the IDE side of the spectrum with many cool extensions that make your life easier.(I am not saying vim doesn't have extensions just that emacs seems to use them more or has more of an emphasis to them) Both are excellent text editors. one will fit your style of living. use that one.
Someone said on Stack overflow, "I use Vim for manipulating text, Emacs to do programming and Firefox to look at funny cat pictures". I agree with that assessment.
For years I enjoyed Borland products, they used Wordstar key bindings.
And then one day it stopped working. I simply had to use the mouse.
I was shocked.
It took me years to recover. I hated it.
Call me a masochist, a few years ago I tried Emacs, it was the only editor with syntax enlighting for Ruby at the time.
Except it was not working, or at least it was not working for me.
I had learned a little bit of lisp however, so it was not a total waste of time.
A few ago I was so frustrated with my editor (Notepad++), that I decided to give Vim a try.
Well... I am french. I can tell you that using Vim with a french keyboard is hell. That, plus copy/paste with the mouse working erratically (that is: more or less depending on the current "mode")... I quickly got frustrated again.
And then, boom, my netbook's hard drive goes back to his creator and I am forced to switch to my Linux netbook. No more Notepad++ there. I am back with SciTe.
Now my friends, may be you will understand it better when I will tell you a little secret I am sligthly ashamed of:
No more buffers, no more windows, no more subdirectory to navigate.Just one big file.
Heaven.
I wish I had seen the ligth before.
All I miss is a little post processor tool, with which I could define "sections" in my big file. Sections that it will dispatch into their own little files.
And when I will move to git, I will write it, and I will make it "bidirectortional", so that I can fetch back changed files, fetch them back into my BIG file that is.
One big file. Simplicity.
Don't worry, be happy.