Split the project specification and the project state

Josh Bjornson 13 years ago updated by Jon Skinner 13 years ago 1
The project specification and the project state should be stored separately (maybe sublime-project and sublime-workspace?). As it is now, it will be difficult to edit the project files (because there is so much state information stored there) and sharing projects doesn't make much sense. The simplicity of the old project files was great but I really like the features of the new projects. Can't we have the best of both worlds? sublime-project (build_system, folders, save_all_on_build, plus any include/exclude instructions). sublime-workspace (buffers, file_history, find_in_files, find_state, groups, layout, select_file, show_minimap, side_bar_visible, side_bar_width, status_bar_visible)

"It may be worth doing this, but I'm concerned about confusing people: people may not know what a 'workspace' is, so they use the project functionality when they'd be better served by using workspaces." http://www.sublimetext.com/forum/viewtopic.php?f=2&t=1444&p=6606#p6623

Sublime Text "internally" manages the state information for other aspects of the editor ("Auto Save Session", "Session"), so why not store the project definitions "externally" and the current state (workspace) "internally"?

By storing these separately, people could more easily share projects and could still have their own local workspaces.

The biggest issue I can see is the possibility of the project and the workspace getting out of sync (if one of the files is moved to a different location).



 This was done in build 2111

I would love to have projects work like .git files.

Instead of having to name a project and having to save a visible file, and then open the project manually, just store a invisible file on the folder automatically and open it automatically when that folder is opened.

You might argue that some projects might involve more that 1 folder. While that is true, there is most certainly a main folder for a project and accessory folders and accessory files. 

If no folder exist, then probably it isn't big enough to be considered a project of to benefit from anything a project have to offer.

How to choose the main folder? Use the 1st opened folder.

Make projects transparent to users. The project name = main folder name. When the user, opens the folder again, load the .sublime-project invisible file, and he/she will have the project and configurations loaded automatically.

Regarding the split project specification vs project state, we could have a .sublime invisible folder (like .git). 

Inside 2 files: .project and .state and possibly others according to taste.

The you could tell version control systems to ignore .state

PS: Windows users might not understand what I'm talking about.

Vote here if interested: http://sublimetext.userecho.com/topic/50873-/


 This was done in build 2111