[plt-scheme] saved window configurations

Yes, I was giving a history of projects as related to dealing with 
collections of files for editing, because I was still doggedly, if 
unsuccessfully, trying to focus on that original aspect of this 
discussion. :)


Robby Findler wrote:
> I think projects are usually associated with things like build options
> and library constructions, etc etc, so maybe you're rewriting history,
> or there are more steps in there.
> 
> Robby
> 
> On 9/26/07, Anton van Straaten <anton at appsolutions.com> wrote:
> 
>>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
>>
>>
> 
> _________________________________________________
>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme