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 wellBut 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 )

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!

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!

tgkeul wrote: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!

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 indifferent 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 thanswitching to an existing open one, there's going to be potential forconfusion/conflict. I know I end up with clones I didn't explicitly want openeda lot. The point being here, GOTO anything is great when you just want tomindlessly 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 thedifferent layout cells, with an invisible group for momentarily unused files.

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

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

Sublime Text 2 is frustratingly close but no cigar.

It is better to remain silent and be thought a fool, than to speak out and remove all doubt

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.

The suggested changes to the projects in SublimeText sounds a lot like a basic implementation of the task-focused interface integrated in Eclipse (Mylyn - http://www.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.