Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: