Beautify buffer on file read! It would be really nice if I could view read-only files as if I had run the beautifier against it. ... It would be cool if I could view edit in my favorite format, then only save my non-beautification changes in the original style.
For slickedit to be able to save your non beautification changes in the original style, it would need to know how to generate that style ...
The TLDR version of what's below is: It's a pipe dream -- a solution can't come as features in editors, it has to come at a lower level through redefining what source code is, and a paradigm shift in how source code is stored.
Long version:
Unfortunatley there are reasons this kind of thing hasn't been done in the industry yet. It's a pipe dream, unless we redefine how source code is stored. There are other implementations that don't require knowing how to generate the non-beautified style. But they aren't practical, for other reasons. Some examples below.
Look up "Charles Simonyi Intentional Programming". One of its facets was it stored source code as more like a database of lexical tokens. Thus formatting was purely a runtime rendering detail -- each developer could tweak his rendering settings to format the source code however he liked, because the formatting wasn't actually stored as part of the source code. It didn't catch on, for various reasons.
Another radical approach that can work is to always save files in a canonical NON-formatted, um, format (e.g. a simplistic but inefficient example is one token per line). Or hook into your source control system and canonicalize files on submission, and beautify them on sync (or checkout). A few other approaches exist as well. But they're all pretty invasive and have to be done at a project level, not an individual level (and it has several technical drawbacks).
Another more complex approach could remember the content state
after beautification but
before editing, and on Save it could compute a diff (with intraline differences) between that content state and the after-editing content state, and apply the diffs back to the non-beautified file. Diff quality is a major weak point in that approach. To avoid diffs one could generate a map of where beautification edits were applied, and keep track of both a non-beautified copy of the file and a beautified copy of the file, and apply all edits to both. But these "duality of editing" approaches have even bigger drawbacks than the other approaches: the duality approaches are very complex and expensive to implement (and let's be realistic therefore more prone to bugs), and by definition they run into ambiguous cases where it's not possible to correctly figure out what the non-beautified version should look like. E.g. any edit range that crosses from a non-beautified area into a beautified area, or vice versa). In those cases what gets saved could have undesirable formatting (make the non-beautified version even less beautiful), which would likely lead managers (or teammates) to banning its use.
