[plt-scheme] saved window configurations

Matthias Felleisen wrote:
> 
> On Sep 26, 2007, at 10:04 PM, Anton van Straaten wrote:
> 
>> However, I wasn't actually arguing for doing that (yet!)  Instead,  I 
>> was saying that generalizing the idea of saving a list of open  files 
>> would provide for future extensibility in that direction,  among 
>> others.  Since DrScheme is an extensible environment,  providing 
>> features in a form that can easily be reused by other  extensions 
>> seems appropriate.
> 
> 
> As Robby pointed out, a product is uniquely determined via its main  
> module. So a useful tool is one that opens all transitive (file ...)  
> dependencies in tabs and/or the module browser.
> 
> [We did have a notion of a project, unless my memory deceives me. So  we 
> are not speaking w/o experience.]

My suggestion was definitely not about introducing a project 
abstraction, or having a way to transitively open all files associated 
with a program.  It's almost the opposite, in fact: the idea of the 
task-focused approach is that one typically only deals with a subset of 
the files in a program at any one time, and it helps if the development 
environment lets you focus on that subset and nothing else.  However, to 
do that effectively, it helps to have ways of identifying those subsets, 
saving them, and reactivating them at some later time.

In general, these subsets tend to cross-cut the overall program in 
almost arbitrary ways: the connection between the files you're 
interested in at any one time may have to do with the dynamic flow of 
execution, or with data structures that are shared across modules, etc. 
  Practically speaking, today at least, there's no way in general for 
the environment to predict what files you need for a task you want to 
perform.  So the task-focused approach lets you identify a set of files 
you're interested in, save that somehow, and reuse it when you need it.

On the subject of projects, where I was coming from when I mentioned 
recapitulating the history of IDEs is that a common path in IDE 
development seems to have been:

1. Simple single-file editor.
2. Support multiple files open simultaneously.
3. Remember the set of open files between invocations.
4. Add a project feature so that you can easily switch between sets of 
"known" files.

This thread began with a request for #3.  For the same sorts of reasons 
that I described above, #3 is a reasonable request, even given 
DrScheme's understanding of modules and ability to traverse the module 
graph.  I was just pointing out that providing #3 in a slightly more 
general form makes it quite easy to do:

5. Support task-focused editing.

That's somewhat orthogonal to whether #4 is provided.  I tend to agree 
that the module browser rather obviates #4, although "projects" are also 
often used to manage non-code resources, which the module graph doesn't 
help with.

Anton