Atom-beautify: Why is atom-beautify permanently changing the formatting style for JSX?!

[derwaldgeist]

I love atom-beautify. But what I really hate is the drastical changes in formatting style it applies once in a while in an update. The most recent versions does a lot of changes to my existing code, making it harder to read and causing unwanted change flags in my version repository.

Some examples:

Placement of tags in return statements

Before:

   return (
      <div>
        <div>
            ...
        </div>
      </div>
    );

   return (<div>
      <div>
          ...
      </div>
    </div>);

Placement of conditional operator

Before:

    const imageUrl = '../../static/images/' + icon + (active
      ? '.active'
      : '.inactive') + '.png';

Now:

    const imageUrl = '../../static/images/' + icon + (
      active
      ? '.active'
      : '.inactive') + '.png';

(I personally would prefer if everything was kept on one line, but that's a matter of taste.)

Placement of expressions in HTML code

Before:

    {enableSpectrumAnalyser
          ? (
            <canvas id="spectrum" />
          )
          : ''}

Now:

      {
        enableSpectrumAnalyser
          ? (<canvas id="spectrum"/>)
          : ''
      }

This has a somewhat better readability, but unfortunately it is not used in this consistent way. Sometimes opening bracket jumps to the end of the previous line.

Don't get me wrong, I really love atom-beautify and its "Beautify on Save" mode. Couldn't live without it. But the frequent changes are driving me mad, and I would really like to know what the reason is for this?

[stevenzeck]

Hi @derwaldgeist. Can you look at which beautifier is being used for these files? You can find out by using the Debug command under Atom Beautify in the menu. Towards the top of the generated file you will see Selected Beautifier, please paste that entire section here.

[derwaldgeist]

Thanks for your quick response. Here's the info you requested. I am using PrettyDiff.

Platform: darwin

Versions

Atom Version: 1.21.0

Atom Beautify Version: 0.30.6

Original file to be beautified

Original File Path: /Users/waldgeist/Documents/Development/htdocs/travelguzz/webapp/packages/travel-user-profile-ui/components/UserContact.js

Original File Grammar: Babel ES6 JavaScript

Original File Language: JSX

Language namespace: jsx

Supported Beautifiers: JS Beautify, Pretty Diff

Selected Beautifier: Pretty Diff

[prettydiff]

I can look at supplying additional options to customize when containers do or do not supply indentation.

The most recent versions does a lot of changes to my existing code, making it harder to read and causing unwanted change flags in my version repository.

Running a semi-language aware diff tool and beautifier I can provide some insight on this. Please be prepared to a long ramble about artificial intelligence that is probably not the answer you are looking for.

---

Beautified code will always impose changes in a history of changes as applied to a text base. Most tools are not truly language aware in an artificial intelligence capacity. Most tools parse a code base from text for a specific reason and then supply output with some level of analysis or formatting. The challenge there is that every analysis of the code is a separate parse operation, or generally no parse operation at all if the analysis is a diff. What that really really means is that even if there is a parse step somewhere in there everything is always actually still a text operation.

So let's talk about diff tools and change logs specifically. Almost all diff tools compare versions of text. There is no language analysis of any kind. Pretty Diff is not entirely successful in this either, and it is something I have been thinking about. So let's go further still and talk about the challenges.

A diff algorithm is a wholly independent consideration from language parsing. A diff operation simply compares two things and delivers output about how they are different according to some criteria. Most diff operations take text characters, split them on newlines, and then compare the text line by line. This makes no assumption upon the precision of the given diff algorithm to correctly identify only the changes precisely or its ability to describe those differences. Let's assume we have a diff algorithm that is always 100% precise.

For the diff to focus only upon code changes it needs to be aware of the code. This prevents differences related to white space, like the code examples above. Pretty Diff cheats this by beautifying both code samples in the same way before running the text comparison. This addresses most language-aware concerns when performing a diff, but it isn't smart enough to qualify as intelligent.

More intelligent would be to generate a parse tree of both code samples and then diff the parse tree. This is the start of an artificial intelligence approach and achieves a fully language aware diff tool, which is awesome for software. I can do this now with less work than what I am doing and superior to any other tool. It doesn't do anything for human users, though, because you will have to provide output that people can read. You have to show the changes in context to one of the provided code samples or in context to a beautified result.

That being said to create a fully language aware and artificially intelligent solution to the problem of language aware comparisons across various applications/tools we need two things:

• A universal parsing scheme that everybody shares. This will enable software to parse text into understood code for more than a single purpose use. The syntax coloring in your code editor is the same parse tree as your beautifier, syntax analyzer, and various other tools. It also means the diff tool is comparing the, already parsed, parse tree and ignoring minor formatting changes.
• A solution to resolve the locations of parsed code tokens back to the precise character index in the original source code so that the original source code can be modified as needed without a separate parse step and without generating a different artifact. Those modifications must somehow be applied in a way that other consuming applications can choose to ignore them.

I think I can solve for these and provide a completely artificial intelligence solution, but this isn't the quick win you likely need. It would require a common format that can be standardized and adopted by the various concerned applications. I have a standard language-independent parse format that I wrote up recently, but it would need to be extended to support context resolution as described in the second bullet point above. I don't know how I would appropriately apply this back to the source text without degrading that source text with modifications. I would need to think through that some more.

[derwaldgeist]

Wow, thanks a lot for your thoughtful answer :-) I have to admit that I still do not really understand why the HTML elements and JavaScript brackets "jump around" between versions (I'm not too much into language parsing and this stuff), but it was a very interesting read, indeed. You seem to be a true wizard.

[stevenzeck]

Atom Beautify is basically a wrapper for beautifiers to be used within Atom. None of it's code actually beautifies anything, it relies on beautifiers to do that. In this case it's prettydiff, which had a major update included with 0.30.6

[derwaldgeist]

I just found another weird edge case where the recent changes actually break code:

Before:

if (participant.user === currentUserId || // ... to the user himself
    participant.observing // ... to participants who are currently observing the conversation
    ) {
      continue;
    }

After:

  if (participant.user === currentUserId || // ... to the user himself
    participant.observing // ... to participants who are currently observing the conversation) {
      continue;
    }

Ok, this was a bit of a strange way using comments, but after the brackets jumped to the previous line, the code was broken as they became part of the comment.

[prettydiff]

Yeah, that is bad. I am moving this to my defects so that I can track it more directly.

[derwaldgeist]

Cool, thanks, that was quick as always. So I am closing this now.