What you're asking for is Virtual space, something that I love too and grew very accustomed to back in the days of Brief and my current "other" editor, Crisp.
Vote it up here:
sublimetext.userecho.com/topic/8 ... ite-space/
We need this because it makes in-line commenting a breeze (something that is valuable from time to time), facilitates column selection, copying and insertion to arbitrary places in the text, and is very handy for working with certain other kinds of text files. When your used to that freedom, the current paradigm feels very constraining, and I still go back to other editors when needed to use this facility.
Done intelligently, it would fill whitespace to the left with spaces where there is text on the line to the left, and tabs (and extra spaces if necessary) where the line is empty if the editor is using tabs as its primary indenting whitespace.
That, along with definable tabstop positions, are my biggest headaches with Sublime. Definable tabstops are needed to allow the above intelligent virtual space behaviour. In Brief I could set tabstops to "5 20 24", which would set tabstops at those columns and the remaining tabstops would repeat the distance of the last two (28, 32, 36 etc).
The trouble with Sublime is that while it's nice for editing "modern" languages like PHP and JS, it's a PITA for working with older languages or other "programmer" text files, for example Windiff output (which tabulates varying-length filename and file CRCs). A file thats been edited by another developer with a a particular IDE/language that prefers tabs and particular tabstops (COBOL being a good example) cannot be brought into Sublime looking right. The usual reason is that tabstops cannot be defined; were that the case, you could load up a file with correct tabstops and everthing looks dandy. The perfect editor should be a one-stop for everyone's editing requirements, and for now I have to drive two editors for my programming needs.
FichtFoll's suggestion on userecho to implement virtual space as a plugin is a possibility. The methodology is to append lots of whitespace to the end of each line in a file, allow "free editing", then trim trailing whitespace on save. But this is less than ideal for several reasons:
- Inability to distinguish virtual space from real space (Brief does this by allowing the cursor to change over virtual space - lovely!)
- Time to append and strip extra whitespace on load (or "start editing virtually") and save with extremely large files
- Inability to support the above-mentioned intelligent behaviour when the user prefers tabs for a given filetype
I hope Jon's considering this.