I almost agree - 

> On 2022-01-26, at 3:27 PM, Chris Muller <asqueaker at gmail.com> wrote:
> 
> I believe there's a reason *Workspaces* shouldn't be able to save --
> because if you're doing so much work that it should be saved, then it
> should be put into a method instead.

I'd argue that there are bunches of doit-code/notes that you want to have safe and not in a method, and the right way to do that is with a fileeditor opened on the file.

I just recently made the FileList open a "Workspace with file saving ability" instead of a very hinky mashup of FileList parts, so at least one part is a smidge cleaner. What I'd urge is making it very clear that a window open on a backing file can save & re-load to/from that file, and that a not-backedup one cannot. And it's really not a difficult thing to arrange for a Workspace to turn into a FileEditor if/when a user chooses to ask for it. Nor would it be a terrible thing to have the option to choose which you get as a default.

But Chris has also just raised another important point about staleness and multiple-source editing of the workspace files. Beating that would require some'interesting' work to do constant auto-saving with the file having a full tagged edit history  in the vein of the Apple approach to Pages/Numbers/Keynote files. It's all a bit much for a simple text view with a good relationship with the compiler...

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Fractured Idiom:- APRES MOE LE DELUGE - Larry and Curly get wet