As with most things, I'm sure this concept has been tried before - I just haven't come across editors that use what I've termed 'Virtual Formatting'. The principle is that there's a floating left-margin that simulates the effect of the padding space/tab characters that are conventionally inserted by the developer or the editor itself to format the code. The editor continously parses code (even when commented-out) as you type and calculates the required indent based on the context where each line-feed is found
I'm developing this idea working specifically with an XML editor as XML has some peculiar problems with formatting characters and it tends to be heavily nested, however I believe many of the principles still hold for conventional code.
Have you experience coding with such a tool or do you have a view on whether it would help or hinder? Would it cause problems with version-control systems? (it detects and strips out all existing padding characters)
Unless you've tried it, the behavior of such a tool is hard to describe, it looks conventional until you actually start editing. I've put up a screencast video showing a prototype in action which demonstrates editing XML, changing it's hierarchy and doing drag/drop and copy and paste operations, and then how formatting is broken/fixed when invalid characters are typed.
Edit All answers/comments have so far been negative - so to attempt to redress balance, some benefits of virtual-formatting to think about:
- No more debates on formatting standards, just place line-feeds where that conforms to your chosen/mandated convention
- Where space is at a premium (in a book/blog/documentation) you can word-wrap but still getting perfect indentation
- Each code-block can have a 'mouse-handle' immediately adjacent to where it starts, not squeezed into the screen edge - click this to select the whole block or inner-block
- Drag, drop and forget - becomes viable for the first time
- No time spent reformatting other peoples code
- No incorrectly formatted code (in the sense that there is none - just the rendering)
- Using Backspace instead of Ctrl+Backspace keeps your fingers on the keyboard guide-keys
- Flexible rendering - adapt rendered formatting to your environment, anyone tried reading code on a mobile phone/small-screen tablet?
- Consider that there are roughly 25% fewer editable characters (in a sample XSLT), doesn't that have efficiency benefits?
Edit - Conclusions so far
Developers have established tools and working methods that efficiently overcome most of the disadvantages inherent in the use of padding characters used for indentation.
There is concern that removal of formatting characters will detrimentally affect some differencing tools.
Developers want the flexibility to 'fine-tune' formatting in such a way that automated rendering could not handle.
The removal of leading spaces/tabs means that a 'code-aware' tool capable of code-formatting is needed to review such code efficiently - a plain-text editor would show no formatting.
Those that feel there may be some hypothetical benefits (to virtual-indentation), have a view that the disadvantages outweigh those potential benefits - conclusively.
Edit - Verdict
The perception of the obstacles and few (if any) benefits is such that it would be unwise for me, as a sole-developer, to pursue this space-free editing concept for general languages. For XML/XSLT, however (because of its special treatment of whitespace), there seems to be some agreement of potential at least.
Edit - Product Shipped
In spite of the generally negative sentiment found here, I went ahead and shipped the editor. I made a free version in the hope it would bring criticism in the form of more concrete issues, based on real experience. Somewhat frustratingly, there have been no complaints so far (in fact barely any feedback considering download volume). I'd like to think this was because users adjusted to the idea so well that they see this as a 'so what?' kind of feature - but there's no way of telling...