Add ability to rename (set a name for) a project

[mehcode]

No description provided.

[sadovnychyi]

Why would you want to add such kind of complexity in this package? In my opinion the project names should be simply a string with list of folders in this project.

[mehcode]

Currently, that is exactly what the project name is. It's just path.basename over each project folder joined with commas.

This was just an idea to be able to add an explicit name. I wouldn't use it myself, but maybe someone wants it.

Project-plus is supposed to extend projects however it can if it adds value. If you or anyone else has any ideas, that's what this issue board is for.

[shemerey]

@mehcode BTW I just want to ask you, what do you think about support external project configuration, for instance if project contains project.json or project.yml etc. we can just load it and apply to current project. Something like http://editorconfig.org/

This way we can keep atom-project-plus clean and simple

[mehcode]

@shemerey I'm not sure what exactly you're asking. What kind of configuration / etc.

When doing something like this we need to remain aware of the project vs. project folder distinction.

---

There is a package -- project-view -- which reads in a name from bower/package/etc. and replaces tree view folder / project folder name with it.

---

On what's possible .. there is a json document that is stored per project in atom. This is what project-plus reads from to load the project. And what it reads from to find projects. We can extend this json document however we want with project specific configuration (if we can figure out what exactly we want to configure per-project). We could even have a command to open the JSON document for manual editing (if that is needed/desired).

[shemerey]

Yes it's better to define what kind of behavior will be expected. I was thinking about atom - per - project setup. For instance you have project where you want to use specific version of rubocop or enable/disable some packages.

for me it looks like

{
 project: {
   name: 'Some New Node',
   packages:[{
     name: 'linter',
     enable: false
  }]
 }
}

again I think it needs some time to rethink, I just found an old discussion about Layered Configuration
might be it's can be useful

[mehcode]

On configuration.. reading more into atom we can already do per-scope (language) configuration (eg.. enable a python package only when in a python file or make the font size 24pt when in a javascript file).

If we want per-project configuration.. it seems possible. We'd add a Project Plus: Open Project Config command. This would open a JSON document of the current project configuration.. that would be editable (much like the Application: Open Your Config command).

I'm currently seeing (what I think is) a big problem that I can't think past. If you've applied any project-specific configuration and you go to edit the global/default configuration (in the normal settings menu or in any command that adjusts the config, like the toggle menu bar shortcut), atom would save the project-specific configuration as the new global/default configuration. As project-manager (the current "big" project package) implements what I'm talking about and also has this issue .. I don't think it's something we can solve without implementing a project specific configuration API into atom proper.

---

1. Add project specific configuration in project-plus with the above drawback (with perhaps a clear disclaimer).
2. Submit a PR for a project specific configuration API to atom core. This wouldn't be that complicated.
3. When the PR lands, use the new API in project-plus -- if it's available -- otherwise keep the shimmed one (until the PR makes its way into a stable atom version).

---

Of course.. we could just do 2 and skip trying to shim it into project-plus.

[shemerey]

2 and 3 Looks good, as for me it make sense to move project specific configuration to atom core, since atom cares about projects.

[mehcode]

This is possible via projects.cson