Rename .jsbeautifyrc to .atombeautifyrc

[donaldpipowitch]

Hi @Glavin001 and @karolyi,

Before leaving (?) the project (#40) I have one last question/advice:
As you've added new languages we are in the need to clarify the relation to https://github.com/beautify-web/js-beautify.

The project started as an Atom wrapper for js-beautify, but it should be treated independent to js-beautify now.
We already added a non-standard .jsbeautifyrc (#9). I would recommend to deprecate the use of .jsbeautifyrc right now and introduce a .atombeautifyrc. This JSON file collects default settings which can be used for every language, but could be overridden for a specific language (and adds language-specific settings). Something like

{
 "_default": {
    "indent_size": 4,
    "indent_char": " "
  },
  "html": {
    "brace_style": "collapse",
    "indent_scripts": "normal",
    "indent_size": 6,
    "max_preserve_newlines": 1,
    "preserve_newlines": true,
    "unformatted": ["a", "sub", "sup", "b", "i", "u"],
    "wrap_line_length": 0
  },
  "css": {
    "indent_size": 2
  },
  "js": {
    "indent_level": 0,
    "indent_with_tabs": false,
    "preserve_newlines": true,
    "max_preserve_newlines": 2,
    "jslint_happy": true
  },
  "sql": {
    "indent_level": 0,
    "indent_with_tabs": false
  },
  "python": { ... }
}

You could even exchange js-beautify for a different beautifier for JS at a later state or use different beautifier for CSS and HTML, but still use it just for JS.

Just my 2 cents :)

[karolyi]

+1 to that. We're way more than just jsbeautify already.

[Glavin001]

+1 for changing the configuration file from .jsbeautifyrc to something like .atombeautifyrc.

[Glavin001]

Should we support both with a deprecation warning or something?

[Glavin001]

• Show deprecation warning
• Provide easy-button for users to automatically upgrade and rename their existing (found) .jsbeautifyrc files

[Glavin001]

Blocked by #56, GUI for messages.

[ilanbiala]

I wouldn't change it from .jsbeautifyrc, because not everyone is using Atom. Also, I would actually just build a settings panel into Atom, because that is more across the board and less specific to each project.

[nemoDreamer]

No longer seems to be picking up the .jsbeautifyrc I have in my project's root...
The settings panel is Ok, although it's massive length makes it very unfriendly to use, but an existing .jsbeautifyrc should override those settings (especially when working in a team that has set such a file globally for use by all IDEs)

[Glavin001]

@nemoDreamer .jsbeautifyrc is still the goto file name, so there should not be any problems. The only time when that file is ignored, is if it is not either JSON or YAML and the parsing fails, then it will error silently and try to find other config files.

[nemoDreamer]

Aha, I'll double-check my quotes etc. thanks!
On Mon, Jun 29, 2015 at 7:39 PM Glavin Wiechert notifications@github.com
wrote:

@nemoDreamer https://github.com/nemoDreamer .jsbeautifyrc is still the
goto file name, so there should not be any problems. The only time when
that file is ignored, is if it is not either JSON or YAML and the parsing
fails, then it will error silently and try to find other config files.

—
Reply to this email directly or view it on GitHub
#41 (comment)
.

[stevenzeck]

Looks like something that will be intertwined with Unibeautify.

[Glavin001]

I was thinking .beautifyrc. Thoughts?

[prettydiff]

If the name is changing why not rename it to .unibeautifyrc in consideration for the future effort.

[Glavin001]

@prettydiff I thought about that, too, however if .beautifyrc is not taken -- I think it is not -- then using only beautify may help strengthen the association between Unibeautify and beautification.

Unibeautify is the product name, however the problem is beautification. Instead of users thinking "I want to use Unibeautify", I want them to think "I want to beautify my code" and Unibeautify is just the implementation detail they consistently choose. In the same way "Google it" and "Search it" are synonymous, I want Unibeautify to become to "go to" for code beautification.

I want .beautifyrc to become the best standard for describing how we declare our code formatting configuration (similar to .editorconfig), regardless of Unibeautify being the runtime. However, let's make Unibeautify the best option available 😉 .

[stevenzeck]

Also, should make whatever that file ends up being easily portable. I can envision teams with their editors/IDEs needing to have the same beautification configuration so their source control doesn't keep picking up unnecessary changes.