I am a wordstar guy, I started with CP/M...

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.

One big file. Simplicity.

Don't worry, be happy.

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.

I am in the process of implementing my proposal (JavaScript & nodejs). It will take a couple of days I guess. I'll keep the HN community posted.

We'll see who's crazy!!! :)

Upvoted because it's in interesting idea. But man, you're crazy :)

Are you sure that "But" is the right word?

Thanks for the compliment anyway. :)

Uh? I thought the purpose of splitting code between different files was simplicity.

It's a lie.

The true reason is purely historical.

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

I am not the only one, see this Python tool for Vim: http://coliveira.net/software/editing-multiple-files-in-a-si...

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.

What about source control, concurrent team work, external libraries, etc.?

"sections" take care of that.

The "one big file" gets processed so that each section is kept in sync with a file.

Again: the idea is about make editing easier, it's an addition, your "one big file" is just a compound "view" over atomic files.

I too like to have code from multiple logical sections of my projects visible on the same screen at times.

Splitting windows in vim works nicely for this purpose.

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.

Wow, I did not know that. I've always just assumed they'd be different buffers. I'll probably be using this a lot in future. Thanks!

Mice are an ergonomic nightmare.

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...

In the lab, they are making good progress with "mind controled" cursors.

If you can control the mouse cursor with your mind... what is the better solution to copy/cut/paste, a keyboard?

Given how long lawsuits can take, by the time a conclusion is reached, mind controled mouses will be there I guess. :)

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)

I've been doing some ruby and php stuff at home and I mostly use vim. But when I go back into work it's back to java and eclipse.

I would love to use vim on my java work but I'd really miss eclipses background compilation and server integration.

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.

I just got TM-style command-T working on my vim setup thanks to wincent, it is a nice implementation: http://wincent.com/products/command-t

It was really one of the only things about TM that made me jealous :)

Also it taught me about <Leader> which I'd never even heard of before! Great way to keep your personal commands namespaced from stock vim.

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.):

http://www.vim.org/scripts/script.php?script_id=1984

I use vim, but not vim exclusively. Every single day, I use gedit, scite, scribes and an IDE - some times in the vi mode.

There is a cognitive load to switching between many editors. That is something Emacs users who always exist in Emacs do away with.

And vim users who only use vim don't?

To the author (and this has been posted to HN before but deserves a reposting for those who missed it):

http://stevelosh.com/blog/2010/09/coming-home-to-vim/

> I was more of an Emacs person

Are there really any benefit of switching from Emacs to Vim? I was under the impression that both editors were pretty much interchangeable.

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.

Vim is on pretty much everything, it starts up quickly, for rapid text editing it's pretty difficult to beat.

Emacs once it's up and running (in emacs server mode at least) is reasonably speedy but much more resource hungry and is an entire operating system.

To put it into perspective, I used org-mode for 6 months and loved it for that alone, but vim just works better for me as a text editor, YMMV.

We were taught basic programming with Emacs, connecting to an HP-UX machine. So we really didn't know much Emacs anyway :-)

It can be better for preventing RSI.

But mostly it comes down to a preference on how to do things.

Wow, I would love a personal Drew Neil (from VimCasts) to read me bedtime stories.

(Also, great site, I'm learning!)