Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Atom Beautify internal API v1.0 #282

Closed
14 tasks done
Glavin001 opened this issue Apr 20, 2015 · 8 comments
Closed
14 tasks done

Atom Beautify internal API v1.0 #282

Glavin001 opened this issue Apr 20, 2015 · 8 comments

Comments

@Glavin001
Copy link
Owner

Redesigning the internals of Atom Beautify for performance, extensibility, and ease of use.

  • Base Beautifier Class
    • For both CLI beautifiers and Node.js beautifiers
    • Fields
    • Beautifier class methods - to be used by Beautifier registry for filtering, etc
      • filter(editor, options)
      • Returns boolean or Error, true if this beautifier is applicable
      • Can be used to detecting if CLI path is set, and if not, the beautifier is effectively unavailable
      • Errors can be returned instead of boolean to indicate that something requires to be installed or setup, such as setting the option for the CLI path
    • API - to be used by beautifiers internally
      • getText()
        • Get text / source code to beautify
      • getOptions(language)
        • Get beautifier options for a given language / key
      • tempFile(name)
        • Create a temporary file. Used for CLI beautifiers to create input and output files to use
    • run(command)
      • Run a CLI command as a shell command
    • lazy-require(package-name)
      • See https://www.npmjs.com/package/lazy-require
      • For performance improvements, packages are lazy-loaded (loaded at usage and then cached for future usage, instead of being loaded at top of file)
      • Only packages that are used will be installed. For instance, a user may not intend to beautify JavaScript and therefore js-beautify would not be installed, unless they did run beautify on a JavaScript file
    • deprecated(warning)
      • Notify the user that something is deprecated. Could be anything from a particular option or how it was used (was string, now boolean, etc) or even that this beautifier itself is deprecated (see replacing rbeautify with rubocop #275 )
  • Beautifier Registry
    • register(beautifier)
      • Beautifiers must register to be available
    • constructor
      • beautifiers are loaded from requireing beautifierNames
    • getBeautifier(editor, options)
      • Return list of applicable beautifiers based on text, grammar, file extension and options provided
      • Use filter method on Beautifier class
    • Support for multiple applicable beautifiers (see replacing rbeautify with rubocop #275)
      • If multiple registers are available for this particular file then display them as a list
        • Note that beautifiers that have not set their CLI path option will not be applicable. Therefore if there are multiple applicable CLI beautifiers, only the one that has been setup (CLI path option set) will be returned as available
      • Select which beautifier used for each language in the package settings
      • Remember choice of beautifier given contents (text, grammar, file extension, options)
@Glavin001
Copy link
Owner Author

@Botv0091 had a great idea with #286: extract the settings from common Atom Linter packages and use them as beautification settings.

The developer API for Atom Beautify could be a package_name to function map and the function would be given the package name, settings of package, and a callback (will these be async? maybe just have it return a promise).

@Glavin001
Copy link
Owner Author

@Glavin001
Copy link
Owner Author

Look into using the object and enum type for Config API: https://atom.io/docs/api/v0.194.0/Config

@Glavin001
Copy link
Owner Author

Supported languages should be separated into their own list and then referenced from Beautifiers. A supported Language should have the following:

  • grammars (Atom grammar, such as JavaScript or CoffeeScript, etc)
  • extensions (file extension, such as js or coffee, etc)
  • shortname (shortname for JavaScript is js, etc; used for prefixing the options)
  • options (list of beautification options)

Glavin001 added a commit that referenced this issue Apr 29, 2015
Done:
- Create base Beautifier class
- All Languages are separate files
- Options are separated for each language
- Beautifiers reference applicable Languages/Options
- Atom Beautify builds and tests can run
  - 19 failures out of 34 tests

TODO:
- Render Language Options to Atom Package Settings
- Support for Language fallback option namespaces
- Support for chosing from multiple applicable beautifiers
@Glavin001
Copy link
Owner Author

Tests are passing! See https://travis-ci.org/Glavin001/atom-beautify/builds/60724610
Almost ready for releasing!

Glavin001 added a commit that referenced this issue Apr 30, 2015
Beautifier can have global language option transforms
with "_" (underscore) key.
@Glavin001
Copy link
Owner Author

Glavin001 added a commit that referenced this issue May 1, 2015
What's new:
- Beautifier options definition supports:
    - boolean - enable/disable
    - string - rename and enable
    - function - transform and enable
    - array - apply complex transformation to multiple options and
      output single option result
- Show "Supported by <beautifiers>" for each language option
    - Beautifiers have a name
    - Beautifier options definition is used to determine if
    language option is supported by a beautifier
- Remove SQL test, since sqlformat is inconsistant
@Glavin001
Copy link
Owner Author

Try something like:

  languages:
      type: 'object'
      properties:
          js_disabled:
              type: 'boolean'
              default: false
              description: 'Disable JavaScript Language beautification'
          js_default_beautifier:
              type: 'string'
              default: 'JS Beautifier'
              enum: ['JS Beautifier', 'Pretty Diff']

@Glavin001
Copy link
Owner Author

Glavin001 added a commit that referenced this issue May 2, 2015
Language config options for:
- disabled - Disable beautifying a language
  - `disabled_languages` no longer works
  - use the options for each language to disable them
- default_beautifier - Preferred beautifier to use for language
  - if there are multiple beautifiers for a language it will choose the
    beautifier the user has set as default. Initially the default
    beautifier is just the first beautifier to register support for that
    language
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant