Projects and Workspaces

[jps]

Currently, there are .sublime-project files (which essentially contain a list of folders), and .sublime-workspace files (which contain the state of a window, including open files and their modifications). When you open a .sublime-project, the associated workspace is automatically opened at the same time.

I’m considering changing this, so that you can open projects and workspaces independently. This would then allow a few things:

• Opening one project in multiple windows, with each window having its own workspace
• Having multiple workspaces for a single project, for example, to work on different features within the one project
• Use workspaces without any associated project files

The downside of this is that workspaces would then be exposed directly in the UI, making things a little more complex, and setting up a project+workspace pairing would required an extra step compared to today. Also, it would imply that the general feature of instance project switching becomes instant workspace switching, which first requires users to understand what a workspace is.

Thoughts?

[prmaple]

Keep the old design,

and add a option that user can choose to add new workspace,

when there’s more than one workspace associated with one project,
ask the user which workspace they want to switch to, when switching.

…?

then the users who don’t understand workspace can do things like old days,
users with requirement of having multiple workspaces can be satisfied as well.

…?

and we can have a set of workspace manipulation as well, like
close all workspaces + open a new one
switch to another one
keep the current one and close the others

[iamntz]

and setting up a project+workspace pairing would required an extra step compared to today.

Probably no one is making many projects on a daily basis, so that extra step won’t be a problem for most.

While you are at this, please make an option to allow removing only one project from the recent projects window.

[senzo]

While you are at this, please make an option to allow removing only one project from the recent projects window.

You can remove single entries here: …/Sublime Text 2/Settings/Session.sublime_session (under “recent_workspaces”). Sublime Text has to be closed while you are doing this, which means you need an other text editor. There are some free alternatives which are sufficient for this task

[senzo]

Currently, there are .sublime-project files (which essentially contain a list of folders), and .sublime-workspace files (which contain the state of a window, including open files and their modifications)

If unsaved modifications are stored in a workspace, multiple workspaces could lead to conflicts. I’m sure you have this on your radar, but just in case…

[BestGreek]

I’m happy with the way it works now. It would be nice if the workspace was maintained without having to go to the Projects Menu and click “Close Project”. Or at least put a keyboard short cut on that command.

[wbond]

From a usability standpoint, the proposed idea of separating workspaces and projects sounds confusing. I personally think the current system is great and I use it all of the time.

It also sounds like much of the functionality that would be gained is possible right now using multiple projects for the same folder(s) and duplicating some settings in those. I’d probably opt for power users to have to do a little more work to set up multiple projects rather than every user have to deal with managing projects and workspaces separately.

[agibsonsw]

I am anti heading in the direction of something like eclipse, with Perspectives, Workspaces, blah, blah. It makes it impossible to just open a file or folder.

[vistago]

I could see a big advantage here with multiple branches. I’m working on this new feature and I’ve got like 50 tabs open with changes in 4 of them. Then Sally comes along and tells me there’s a terrible production bug. So I stash and switch to master. But now I’ve got tabs open for files that no longer exist on my drive, and I’ve got changes in 4 files that I didn’t want to have to save yet, and that file I renamed earlier is asking me to save the open tab.

Currently, to avoid problems when the above happens I save all my changes, close all my open tabs, then stash. Multiple workspaces would let me just create a new fresh workspace for master and get to work. And after I’ve fixed the bug in production I can go back to my feature and I’m exactly where I was.

I think to do this right it would need really good UI. I get the complaints above that it can make things complicated, but I do think there’s value here if it’s done right.

[iamntz]

I think to do this right it would need really good UI. I get the complaints above that it can make things complicated, but I do think there’s value here if it’s done right.

Probably something similar with syntax selector (bottom-right) would be just fine?

[Clams]

Like wbond, today I have multiple project for the same set of directory, and i basically use to be able to switch quickly from one workspace to another, it works really well
But if you do it, I think we need the same kind of quick switch from one workspace to another, all belonging to the same project.
I think the advantage would be that we get always a short list when we want to switch from one workspace to another. Because with the current implementation, if you start to have 3 or 4 different project each with 3 or 4 different workspace the list start to be long (even though the quick search helps a lot )

[sublimator]

Or just prefill text like command palette…

Out of interest how many people keep their sublime project files outside the project root?

[nick1]

Out of interest how many people keep their sublime project files outside the project root?

I do, for a handful for projects where the code is on a network mounted drive. It’s much faster to load the workspace when it’s saved locally.

[tgkeul]

There were times I wanted to differentiate between projects and workspaces. But I learned using sublime projects like workspaces and get used to it. It is quick, reliable and simple.
I see no need for a change anymore.

Sometimes I#m forced to use Eclipse. An example how to make it complex and hard to use - horror!

[qgates]

Good to see you pop up Jon, sounds like stuff’s happenin… I like the proposed idea, it gets my +1 so long as the UX is done nicely. As a starting point for the UX I’d like to see:

• drag and drop for project and workspace files handled nicely
• API hooks to load and save
• switch projects and workspaces in the current window or open in new window, with definable shortcuts (palette, keyboard, menu)

Basically, keep things flexible.

A simple way to have the new and old behaviour is a preferences bool “projects-old-behaviour”. If true, projects load and save same named workspaces as per current behaviour.

On a related note, one thing that really irks me with sublime is not being able to load it up from the command line completely blank and sessionless (for git comments etc.). If I try to do this with a project, I get 2 sublime windows, one with the last session/project, and one with the project I’m loading. Which is focussed, at least on Windows, is anyone’s guess also making this a nightmare to use; this stuff’s buggy atm. What I’d like is subl --nosession that just loads a sublime window devoid of any projects, files or workspaces. Since sublime uses the same process for all windows, things get a little clunky if sublime is already running, especially on Unix, but we can use --multiinstance to deal with that.

Using --multiinstance allows us to run our own sublime process, but we can’t avoid last sessions being loaded up, and I’d like to be able to run a sublime instance with nothing loaded in and no state saved. So then, when I run sublime again normally, my usual prior saved session loads up.

At present the UX of sublime fits the traditional launch methods (ie. commandline) of editors badly while being friendly for the GUI user. Separating workspaces and projects is a great idea, but don’t lose sight of how to improve related aspects of what’s already there. Simplest would be a --traditional flag that launches multiinstance, no session and indicates this run mode in some way on the titlebar. Closing the window isn’t allowed without confirming file saves, ie. no hot exit.

Another idea (from Crisp, my “other editor”) would be to offer a directory specific state; project and workspace, loaded --multiinstance when subl is launched from that dir. This workflow fits really nice for the command line user. You launch sublime from project X directory, and it’s workspace and project state load up. Launch from somewhere else, you get a the project and workspace of that folder.

Ok… Stop here, I’m drifting off-topic…

ps. --help doesn’t work in Windows either
pps. ok, totally offtopic, but pretty please for removing the menu in Linux!

S

[bizoo]

[quote=“tgkeul”]There were times I wanted to differentiate between projects and workspaces. But I learned using sublime projects like workspaces and get used to it. It is quick, reliable and simple.
I see no need for a change anymore.

Sometimes I#m forced to use Eclipse. An example how to make it complex and hard to use - horror![/quote]

+1
I’m happy with the way it works now.

[sublimator]

TL;DR, 1: project, 1: workspace, M: windows, M: view arrangements

Should a workspace map 1:1 with a window? On reflection, I don’t believe so.

What if, like others have pointed out, you have multiple clones of files open in
different windows.

I think clone state should work across windows, likewise with undo state.

With the GOTO anything panel current behaviour of cloning a new file rather than
switching to an existing open one, there’s going to be potential for
confusion/conflict. I know I end up with clones I didn’t explicitly want opened
a lot. The point being here, GOTO anything is great when you just want to
mindlessly navigate to a file, and not search your sidebar / tabs. Being easy,
people will gravitate to that behaviour.

( side note: I’d prefer cloning to require an explicit command and goto anything
to focus on previously used clone)

What I really want is a way to quickly set the positioning of views amongst the
different layout cells, with an invisible group for momentarily unused files.

I believe for this to work nicely the switching must be lightning fast and undo
not to be lost between switches.

I think being able to script and auto tile arrangements with named groups would
be awesome.

Sublime Text 2 is frustratingly close but no cigar.

[sublimator]

That was a bit muddled upon reading back, but I think having separate sessions where the state of the same files across multiple windows gets in conflict is not a great idea.

I’m talking about issues of having a window map to a *.sublime-workspace file and the sessions being independent for everything but project settings/folders.

[handycam]

I just would like to see Projects only save their contents (the files and folders opened or added via drag) when the user saves it.

This way, even if I close some files the are still in the Project. I can open the Project again and get all my files back.

To me, I like to set up a Project with every file that is involved with a project at work. These are often files scattered across dozens of folders. Adding these folders is not an option, since they contain hundreds of unrelated files. Therefore, the only way I can group the files that comprise a project is to add them one at a time. This is OK, as long as the project file would remember the files involved. As ST currently works, if I close a file it’s gone from the Project instantly. I need to remember what files I worked on and maybe re-open them. This is not helpful. The only way to maintain all the files in the project is to keep them open, which clutters my workspace.

So, please, I hope a way can be devised to save a project and closing or adding new files just “dirties” the project window – prompting for a save when you close the project window.

[jbjornson]

The suggested changes to the projects in SublimeText sounds a lot like a basic implementation of the task-focused interface integrated in Eclipse (Mylyn - eclipse.org/mylyn/). Although a lot of people here justifiably don’t like eclipse (I agree that it is extremely bloated), this is a really fantastic and powerful feature of Eclipse. Except for certain tasks I try to keep my distance from Eclipse, but every time I do use Eclipse I am reminded how cool the features of Mylyn are.

For those of you who are not familiar with Eclipse, Mylyn is a “task-focused interface”. You create a “task” in Mylyn and it gives you a filtered view of the project with only the files that you have viewed or edited while working on that task (referred to as the task context). It is extremely helpful when switching between different topics on the same code-base (helps with your mental context switch). For example, if you are working on some back-end processing logic, you don’t need to have all of the front-end code cluttering your view.

From the Mylyn website:

Mylyn’s task-focused interface reduces information overload and makes multitasking easy. Mylyn makes tasks a first class part of the IDE, integrates rich and offline editing for ALM tools, and monitors your programming activity to create a “task context” that focuses your workspace and automatically links all relevant artifacts to the task-at-hand. This puts the information you need at your fingertips and improves productivity by reducing information overload, facilitating multitasking and easing the sharing of expertise.

I know that a full implementation of Mylyn’s functionality is out of the question (and would be too much), but being able to have multiple views into the same project would go a long way towards bringing these features to SublimeText. If each workspace also kept it’s own closed file history , I would be a very happy camper. For now I will continue to mimic this behaviour by creating new projects with the same linked directories for each task.