The one advantage to be gained is that users wouldn't control indentation characters -- meaning that the editor could be opinionated about one or the other, and the user wouldn't need to worry about accidentally messing it up.
I think of it more as a demonstration of a general principle. There's no reason why we shouldn't abandon flat text files. Some huge fraction of development shops aren't really coding in flat text files anymore -- the IDE being completely essential to the shop's process at this point. Many IDEs have to basically parse the source to develop live objects to have their full capability, anyhow. Environments like Smalltalk have been operating without source files for decades now. Instead of source files as we know them, you basically have textual transaction logs for changing the source code database. This even makes the system more powerful, flexible, and robust thank traditional text files.
This is like the idea of storing the code in a richer file format rather than just text. It would be up to the editor to format it and present it appropriately. This would also allow for code comments, pre-post checks, assertions, and other metadata to be embedded into the code without having to be typed in some meta language or language extensions in the plain text.
I would like to experiment with something like that but given how much existing plain text code there is I don't see this happening any time soon.
> but given how much existing plain text code there is I don't see this happening any time soon.
But this could work with existing code through simple translation. It could even possibly be converted to an outline when read into the outline-based editor and then be rewritten as plain text when saved.
I have worked on a scheme that makes ES6 look like coffeescript when in the editor while stored as normal javascript on the disk. This would solve the problem of working in (almost) Coffeescript on someone else's project written in Javascript. I'm stuck right now because I can't get the number of changed lines in GIT down to an acceptable level. See https://github.com/mark-hahn/jsw.
It could, but the goal would be to store the code as rich text not plain text. So it would have to be decomposed to an AST and then stored in some structured format - XML for example.
This means that all of these existing tools that deal with just plain text would need modifications to handle the richer file format.
Having it as rich text in the editor and then saving it out as a plain text file means you're just making a rich code editor.
The biggest argument against this is future proofing development. Even if your tools change and/or are lost, plain text will live on. Your special formatting or behind the scenes gymnastics to make the text look okay, may not.
The plain text to outlined code is pretty much what a compiler does. The proposal is akin to the idea of editing code as an AST rather than a textual representation. Until our source control software supports the idea of seeing code files as more than just lines of text, this idea is likely to go nowhere IMO.
It would be neat to see this in a RCS though. Imagine seeing a diff like:
renamed foo() to bar()
bar() changes:
+ if (baz) { ... }
- if (quux) { ...}
17 comments
[ 3.7 ms ] story [ 47.6 ms ] threadFixt
And conversely, if anyone makes the argument of "How to Solve Spaces vs. Tabs Forever", tell them to just use spaces. Problems solved!
If only we could.
I would like to experiment with something like that but given how much existing plain text code there is I don't see this happening any time soon.
But this could work with existing code through simple translation. It could even possibly be converted to an outline when read into the outline-based editor and then be rewritten as plain text when saved.
I have worked on a scheme that makes ES6 look like coffeescript when in the editor while stored as normal javascript on the disk. This would solve the problem of working in (almost) Coffeescript on someone else's project written in Javascript. I'm stuck right now because I can't get the number of changed lines in GIT down to an acceptable level. See https://github.com/mark-hahn/jsw.
This means that all of these existing tools that deal with just plain text would need modifications to handle the richer file format.
Having it as rich text in the editor and then saving it out as a plain text file means you're just making a rich code editor.
1. Edit it with an IDE that supports soft-tabs.
2. Save the actual text-file with spaces, for explicit positioning and uniform appearance.
It would be neat to see this in a RCS though. Imagine seeing a diff like: