Add the concept of an atomproject file to atom.
#16845
Conversation
|
Sorry I'm late. ❤️Took me a full six days to notice this and add the new format to everybody's favourite file-icon package. Oh yeah, I also updated Atom's manpage. You're welcome. |
Summary: Monkeypatch atom.config and atom.project to support project specific configs. Once atom/atom#16845 is merged into atom, makes it into release, and then becomes supported by Nuclide, this should be removed. Note that this monkeypatch is behind the nuclide-atomprojects GK. Reviewed By: matthewwithanm Differential Revision: D7118459 fbshipit-source-id: ee6605614db823914906746a9ba5939d86bd68aa
|
should this line "pathsToOpen.push(path.dirname(projectSpecificationFile))" be changed to "pathsToOpen.push.apply(pathsToOpen, contents.paths)", cause when I open a new window it didn't open the path specified by the "paths" variable in ".atomproject.cson", instead opened the path that the ".atomproject.cson is at. |
|
That was long overdue, thank you for that awesome piece of work! But I still have one question: why do I have to explicitly add the Seems to be an unnecessary burden to me to start Atom using that |
It could, but that'll probably bite you someday when you open an unfamiliar path in Atom to make a quick edit, and wind up opening craploads of unfamiliar folders because you didn't notice there was an Good command-line utilities should be dumb (in the sense of not trying to be "smart" by "guessing") and as predictable as possible. If writing out alias @='atom -p .atomproject.?son'Replace |
|
I honestly can't think of a use case where I would want to define files to open in a (project specific) config file. Why would anyone do that? I have a very specific and current other use case though: I've just joined a new team a week ago and they're - for whatever reason - using the .md file suffix for their handlebars templates. I'd love to have a way to simply add a Which always gets automatically loaded whenever I open that project. No matter if via Dock, via Project Manager or Recent Files 😕 When talking about predictability: I'd throw consistency into the ring. I want to have always the same config when opening a project folder, no matter which way I open that project 😉 |
That was just an example. My point is that it goes against user expectations. There could be any number of reasons why an unfamiliar config file resides in a project directory - it could be a folder of test fixtures, files downloaded en masse from GitHub searches (it does happen...), or even a confused user who accidentally checked their config into a package's version control and forgot about it (and never noticed).
Back to that ol' "programs should not be smart-asses" thing again. =) If a user didn't want to load a project's config when opening a directory, they'd have no obvious way of saying "No Atom, don't load that damn file!" |
|
@Alhadis What about some notification like "I found project file and loaded it" with button "No, don't!"? |
|
That's going way too far... If automatic loading of project-configs are desired, I'd recommend setting something like this in your environment: export ATOM_AUTOLOAD_PROJECTS=1Alternatively, So to always load export ATOM_AUTOLOAD_PROJECTS="$HOME/Projects:$HOME/.atom"Or just set it to |
|
These settings will override global settings. Is this a problem for functionality such as zoom. From my quick playing around with this, it seems that the zoom function no longer works if I override |
|
Is there a way to save current project layout as atomproject config? |
|
@YurySolovyov No, that is out of scope for this change. |
|
@lee-dohm is there a ticket I can follow? |
|
No, and I would be against a change like that since the concept of the |
|
|
Description of the Change
Adds explicit project configs to Atom. Ie: One can now create a
*.atomproject.{json, cson}containing an array of root paths, as well as an associated config. Opening this file from the command line with the -p flag (ie:atom -p ./foo.atomproject.jsonwill, in a new window, open up all the paths specified in the file, as well as layer the configurations specified in the file in memory on top of the global config, at a level of precedence higher than settings from ~/atom/config.json. Atom windows not opened through the -p flag will not have any of the project specific settings.This PR does not add the ability to launch atom from a project file through the UI, although it would be fairly simple to implement using the APIs (ie:
atom.project.replace) added in this PR.Please note that this PR is separate from (RFC-001](#16698). As @damieng has stated elsewhere, this RFC will be tweaked to be for the root-folder level config that LSP needs which IDE team will develop. That RFC will only deal with root folder configs (not project level).
Example of launching an atomproject on Giphy:
https://giphy.com/gifs/1wqpNX1QdxAflmELbh/fullscreen
EDIT: Project configs must now match personal configs - ie: the config in the above gif would need to be
{'*': {'core': {'themes': ['one-light-ui', 'one-light-syntax']}}}Alternate Designs
When a user invokes
atom -p. *.atomproject.json,command-line-parser.jschecks for a -p flag, and if it finds it, passes the data from the file over the process boundary to the newly created atom window. There, it callsatom.project.replacewith the contents of this file. This API,atom.project.replace, usesproject.setPathsto replace the paths on the atom window. An alternative way to do this could have been to use thepathsToOpenarray inparse-command-line.js. Doing this would allow other command line options (ie: --test) to use the paths field of the atomproject file as well. I chose not to use this approach, and instead to just useproject.setPaths. This is so thatreplacedoes all of the work of replacing an atomproject, instead of just doing most of it and delegating the paths bit to the Atom application process launcher. Additionally, this design simplifies the task of implementing UI to swap atomprojects.In terms of layering project settings on top of the global config, this PR takes a very different approach to an earlier PR which was meant to add root-folder level config. First, there is no "dirty state" (settings that have been set within the current atom session), or "settingsContexts" (seperate in-memory settings objects) - instead, project configs are just implemented using the existing source properties on the config settings. No settings are saved to disk, and only layer on top of the atom window spawned for the project.
Why Should This Be In Core?
This change allows users to set config settings for a set of paths, which is useful for teams or individuals who want settings specific to a particular project. It also lays the groundwork for features like suggested packages (which could live inside a .atomproject file).
Verification Process
Unit testing in config-spec, project-spec, and extensive manual testing of atomproject files.
Applicable Issues
(RFC-001)(#16698)