RFC-001: Project-Specific Configuration #16698
Conversation
There was a problem hiding this comment.
Does it need to be explicitly stated what happens if the user removes a project folder and adds a new one?
This is implied, but maybe it should be stated somewhere that a user must change the project config file in order to change settings manually. I'm still not sure I like the idea of the user being unable to see in the interface anywhere where a setting is coming from, but as this will initially be in limited use a UI showing that and allowing editing of project settings can come later.
|
|
||
| There are two configuration files: the global `~/.atom/config.cson` and the project-specific `atom-config.cson`. (Hereafter these two files will be referred to as the "global settings" and "project settings" respectively.) The project settings file is stored in the root directory of the project root. | ||
|
|
||
| When reading from the configuration using `atom.config.get()`, the contents of the two configuration files is merged using [`Object.assign`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/assign) or some similar mechanism, with the values in the project settings taking precedence over the global settings. For example: |
There was a problem hiding this comment.
Note that the example retrieval is from within the project, and maybe add an example for global retrieval?
| atom.config.set('editor.tabLength', 2, {project: true, scopeSelector: '.source.gfm'}) | ||
| ``` | ||
|
|
||
| **Note:** [Behavior is undefined](https://blogs.msdn.microsoft.com/oldnewthing/20140627-00/?p=633) when there are multiple project roots that have `atom-config.cson` files whose individual values are different. For example, given a project that has two project roots "foo" and "bar" with project settings like the following: |
There was a problem hiding this comment.
Should this fall back to the global value instead?
There was a problem hiding this comment.
Just to be clear, leaving it undefined as to what happens is valid at this point as far as I'm concerned.
There was a problem hiding this comment.
Leaving this alone for now.
| console.log(`fontSize = ${fontSize}`) | ||
| // "fontSize = 16" is output | ||
|
|
||
| atom.config.observe('editor.fontSize', (value) => { console.log(`fontSize = ${value}`) }) |
There was a problem hiding this comment.
This needs a // "fontSize = 16" is output line after it. (Since observe callbacks are called when initially observing).
There was a problem hiding this comment.
Ah, good point ... thanks!
|
|
8000
||
| ## Drawbacks | ||
|
|
||
| It introduces complexity and some non-determinism into the Atom configuration system. |
There was a problem hiding this comment.
Maybe explicitly note the potential for user confusion and increased support tickets?
|
I'd really like us to be able to support root-folder level configuration setting - we need this even more than project level in atom-ide. I think it could exist with the api proposed here but with a different get/set;
Get would also need to specify the path - we can't automagically know which folder to get it in as by the time atom.config.get happens it's probably lost all app-level context of where that call was made and what folder it could possibly relate to. |
|
How do you propose Note that I definitely prefer specifying a root-folder when setting a value as that removes the |
|
Yeah the project level stuff seems fraught with confusion until we have an explicit project system with it's own configuration of folders and settings. e.g. a damien.atomproject file with; {
"rootFolders": [ "/src/first", "/src/second" ],
"configuration": {
"core": {
"editor": {
"tabLength": 2
}
}
}
}I'm +1 on just extending set/get/reset/observe to allow them to specify a root folder. There will also have to be some expectation set-up that not every setting will work per-folder, e.g. editor.fontSize probably won't be happy switching back and forth as you jump between files? @Arcanemagus not sure I understand the question. |
|
Meeting outcome from discussion with Facebook on project config:
|
Awesome, that should cover the essentially same need that I see issues for on the
Currently most of the
From the last time I looked I think most of the LSP clients are currently just using |
|
@lee-dohm looking at the outcome of the meeting about this RFC. It looks like a lot of work needed to be done and back then Atom had the capacity to do it. However, right now we don't have an IDE team and also we don't see ourselves doing a rework on the File/Atom menu a bit to make the project stuff clearer. I am closing this for now, but happy to reopen when there is capacity. |
Add a proposed design for project-specific configuration.
Rendered view
/cc @daviwil @damieng