Robert Roessler:
It just seemed that since a) SciTE can already save the current set of
buffers and minimal state info, b) bring this back, and c) handle
explicit loads and saves of *named* buffer "bundles" ("sessions"),
substituting in the "last" named bundle for a) and b) shouldn't be all
that difficult... and might even be desirable.
Features may be added incrementally with each making sense when it
is added but resulting in a poorly integrated application. If I had
better foresight, I probably would have not included the Open and Save
Session dialogs and instead just had a command line -loadsession option
with that being the automatic save name as well (if save.session is on).
Starting a new instance of SciTE is fairly fast (partly because it
doesn't load as much state as VS) and tying the session to the whole run
is simple.
The session file name may be available as $(SessionPath) but I'm not
sure how reliable that is.
I even invoked the example of everyone's favorite IDE, VS - and
emulating its behavior I would take as the guide for how this should
work in cases such as the one Neil brings up (and for this, I believe
that it silently updates the current project first - yup, it does, I
just checked on VS 2003). ;)
VS doesn't really allow you to manipulate session files: they seem
to be just a side effect of project files.
Since you don't sound like you want to do this yourself, Neil, would
this come under one of your "I'll accept a well-written patch..." edicts?
I'm not sure yet.
What happens when you make a mistake: Buffers | Close All and there
is no way short of killing the process to stop losing all that precious
session state? With the current functionality you just omit performing
the save session.
Neil
_______________________________________________
Scite-interest mailing list
[email protected]
http://mailman.lyra.org/mailman/listinfo/scite-interest
