Author Topic: Beautify buffer on open  (Read 844 times)

jwdonahue

  • Community Member
  • Posts: 10
  • Hero Points: 0
Beautify buffer on open
« on: February 12, 2012, 01:45:48 am »
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.  Currently, the beautify button is disabled on read-only files and on writable files, beautifying marks the file as changed.  It would be cool if I could view edit in my favorite format, then only save my non-beautification changes in the original style.

o Beautify buffer on file read
    o Mark beautified buffer as changed (for writable files)

Graeme

  • Senior Community Member
  • Posts: 2357
  • Hero Points: 309
Re: Beautify buffer on open
« Reply #1 on: February 12, 2012, 05:09:06 am »
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.  Currently, the beautify button is disabled on read-only files and on writable files, beautifying marks the file as changed.  It would be cool if I could view edit in my favorite format, then only save my non-beautification changes in the original style.

o Beautify buffer on file read
    o Mark beautified buffer as changed (for writable files)

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  - and if it knew how to do that, you could run a command that beautified back to the original style when you'd finished.  You might find that a tool like uncrustify gives you more formatting options but it seems to me that repeatedly beautifying a file runs the risk of unintended changes occurring.  Maybe SlickEdit's "source diff" will help you.  You could use it to check whether unintended changes have happened.

chrisant

  • Senior Community Member
  • Posts: 1410
  • Hero Points: 131
Re: Beautify buffer on open
« Reply #2 on: February 12, 2012, 07:16:39 am »
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.

ealbers

  • Community Member
  • Posts: 44
  • Hero Points: -6
Beautify buffer on open
« Reply #3 on: July 12, 2016, 10:32:12 am »
Suggestion, teams of programmers often have this issue.
Format one way on loading a document
Format another way on Saving!
This way everyone 'sees' their favorite format, but it gets checked into the repository the way 'everyone else' likes it.