8000 Config API changes · Issue #3674 · atom/atom · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content
This repository was archived by the owner on Mar 3, 2023. It is now read-only.

Config API changes #3674

Closed
10 tasks done
benogle opened this issue Sep 30, 2014 · 5 comments · Fixed by #3697
Closed
10 tasks done

Config API changes #3674

benogle opened this issue Sep 30, 2014 · 5 comments · Fixed by #3697
Assignees
@benogle

Comments

@benogle
Copy link
Contributor
benogle commented Sep 30, 2014

Status: Donezo

Via @nathansobo

Abstract

This roadmap proposes replacing scoped properties with scoped config settings. In short, you'll be allowed to specify a CSS selector when calling Config::set, and Config::get will optionally accept a token against which to evaluate its selectors. This roadmap also proposes adding a Config::onDidChange method to replace the callNow property to ::observe.

Tasks

Config schema

#3613

Add types and things to the config.

  • Use a schema for specifying config
  • Deprecate all the getInt style methods
  • Eliminate callNow: false
  • Add Config::onDidChange API

Move syntax properties into config

#3697

Currently Syntax supports scoped config settings. It doesnt make sense to have multiple config systems. This unifies them and will put us in a good place to do scoped configs (eg. enable softwrap for markdown, hard tabs for bash, etc). See #2593, atom/language-make#3

  • Add optional selectors to Config::get/set
  • Forward deprecated writes to atom.syntax to atom.config
  • Forward deprecated reads on atom.syntax to atom.config
  • Read from atom.config instead of atom.syntax
  • Register scoped properties with atom.config instead of atom.syntax when loading packages.
  • Allow scoped settings to be observed

API

Writing Scoped Settings

We can add an optional selector as the first argument to Config::set and Config::setDefaults. For example, this enabled soft-wrapping on anything in the .gfm scope, but disables it for code blocks within markdown. (We would need to update the editor to be capable of honoring these settings within a given scope).

atom.config.set('.gfm', 'editor.softWrapped', true)
atom.config.set('.gfm .source', 'editor.softWrapped', false)

Reading Scoped Settings

We can update Config::get and Config::observe to take an optional token that must match against selectors. Here's an example of determining if we should use soft-tabs in a particular context:

token = editor.tokenForBufferPosition([5, 3])
atom.config.get(token, 'editor.softTabbed')

Observing Scoped Settings

We can also extend the API to allow scoped settings to be observed. This should assume that the token is immutable, meaning that if the token's scope changes we'll need to set up a new observation:

atom.config.observe token, 'editor.softTabbed', (value) -> # ...

Eliminating callNow: false

One final change, unrelated to the scoped properties, is to add a simple ::onDidChange method to Config that replaces the callNow: false option to ::observe. This brings the config API into line with changes we've made elsewhere, where ::observeFoo calls the callback immediately and ::onDidChangeFoo calls it only on the next change.
@benogle benogle self-assigned this Sep 30, 2014
@benogle
Copy link
Contributor Author
benogle commented Sep 30, 2014

Here is what was implemented as far as the schema:

@config:
  fontFamily:
    type: 'object'
    default: ''
  fontSize:
    type: 'integer'
    default: 16
  lineHeight:
    type: 'number'
    default: 1.3
  someArray:
    type: 'array'
    default: ['ok', 'yeah']
    items:
      type: 'string'
  invisibles:
    type: 'object'
    properties:
      eol:
        type: 'string'
        default: '\u00ac'
      space:
        type: 'string'
        default: '\u00b7'
      tab:
        type: 'string'
        default: '\u00bb'
      cr:
        type: 'string'
        default: '\u00a4'

See https://github.com/atom/atom/blob/master/src/config-schema.coffee

@benogle benogle mentioned this issue Sep 30, 2014
Closed
21 tasks
@abe33
Copy link
Contributor
abe33 commented Oct 1, 2014

It'll be great if there was a config API to enable new config types. As I understand the new API, types are used for both validation and UI (on the settings-view), so maybe something like this could do the trick for both:

class MyCustomSettingType
  coerce: (keyPath, value, schema) ->
    # ...
  validate: (keyPath, value, schema) ->
    # ...

atom.config.registerType 'custom', new MyCustomSettingType

As for the UI, the type object could provide a specific method to return a view to use, the only contract for the view would be to dispatch a change event with the value. Maybe something like this:

class ColorSettingTypeView extends View
  @content: ({keyPath, value, schema}) ->
     @input outet: 'input', type: 'color', value: value

  initialize: ->
    @input.on 'change', => @trigger 'change', {value: @input.val()}

class ColorSettingType
   coerce: (keyPath, value, schema) -> #...
   validate: (keyPath, value, schema) -> #...
   getView: (keyPath, value, schema) -> new ColorSettingTypeView({keyPath, value, schema})

Do you think this is possible?

@benogle
Copy link
Contributor Author
benogle commented Oct 1, 2014

It is currently implemented with eventual extension in mind. At some point, I'd like to open it up to do what you describe. You can add new config types at this time, but the methods to do so are private. I dont want to make extension of the types public until we have a better understanding of how people might want to use them, what extensions are needed, etc.

As far as view rendering is concerned, I'd rather not register view rendering with the model like that. I think rendering is the purview of the settings view. What if a new, competing settings view came out and wanted to render things differently? I'd like to register any setting renderers / editors on the settings view.

Also, setting renderers are not necessarily bound to a type. They might be bound to some other key like enum, or minimum. eg. when enum is specified, show a select list no matter the type. When something is an integer or number type with minimum and maximum specified, show a slider, but a textbox when no min and max are specified.

Basically, I want more usage and thought in the current schema additions before committing to an API.

@benogle
Copy link
Contributor Author
benogle commented Oct 1, 2014

And we're adhering pretty strictly to (parts) of json schema: http://json-schema.org/latest/json-schema-core.html#anchor8 ; http://json-schema.org/latest/json-schema-validation.html#anchor76. We currently do not have any special additions to it. When we add extensions or allow for it, I want to be sure we are doing the right thing.

@benogle benogle mentioned this issue Oct 1, 2014
Merged
7 tasks
@benogle benogle mentioned this issue Oct 3, 2014
Merged
13 tasks
yujinakayama added a commit to yujinakayama/atom-auto-update-packages that referenced this issue Dec 19, 2014
@yujinakayama
Fix error "Uncaught RangeError" with Atom 0.162
c189bb9 
The Config::observe no longer honors the callNow option
in favor of::onDidChange.

* atom/atom#3674
* atom/atom@b0731af

This fixes #10.
@lock
Copy link
lock bot commented Jan 25, 2019

This issue has been automatically locked since there has not been any recent activity after it was closed. If you can still reproduce this issue in Safe Mode then please open a new issue and fill out the entire issue template to ensure that we have enough information to address your issue. Thanks!

@lock lock bot locked as resolved and limited conversation to collaborators Jan 25, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@benogle benogle

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Add scoped settings to config atom/atom
2 participants
@benogle @abe33
0