Feature request: switchable saveable edit sessions

[mako]

I work on a large product (hundreds of MB of source in thousands of files). We use multiple languages: C++, Java, Perl, HTML, and XML mostly. Because all these pieces inter-relate, I have a single workspace for all of them, with projects to break them down by language type and major component.

It is often the case that while working on one development project I must take a break to consult on another or fix a bug in some other area of code. I would really like the ability to save the set of files and bookmarks I am currently working on, close them all, and work on some others for a while. Then, when I am done with the interruption, restore the saved session with all the files I had open, and all the bookmarks that were current at the time I saved the session.

As far as I know, open files and bookmarks can only be saved with a workspace. But the workspace also represents the composition of a set of projects and the tag database for all those projects. I don't need another workspace, and don't want the overhead of maintaining multiple copies of the tag database and project list (my workspace tag file is 33 MB, and can take 10's of seconds to refresh when I pull in a set of changes from the source code control system). All I want to do is be able to quickly switch between different sets of open files and bookmarks within the same workspace.

If there is some way to get this capability with a set of macros that someone has developed, please post a pointer to it - I don't have the time to learn the Slick-C environment well enough to develop it myself.

Thanks.

[chrisant]

One way to achieve this with the current product, is to have N copies of the workspace.
This works because edit session state is per-workspace.

For example, to have 3 switchable edit sessions, make 3 copies of the workspace.
All 3 copies can even reference the same .VPJ files! 

Switching between workspaces will remember save the edit session for the current workspace and close the workspace, then open the new workspace and restore that workspace's edit session.

[dunkers]

Is there a way to share the workspace tag file? If one is editing the project files in one workspace then the tag file in the other workspace becomes out of date. One could, of course, re-tag the project whenever one switches, but that could rapidly become something of a drag (and forgotten the one time it's really really important).

[mako]

One way to achieve this with the current product, is to have N copies of the workspace.
This works because edit session state is per-workspace.

For example, to have 3 switchable edit sessions, make 3 copies of the workspace.
All 3 copies can even reference the same .VPJ files! 

Switching between workspaces will remember save the edit session for the current workspace and close the workspace, then open the new workspace and restore that workspace's edit session.

As I mentioned in the description of my environment, my workspace is quite heavy-weight, not something I want to copy every time I have a new development or programming task to work on. I want a light-weight solution, so that I don't have to think twice about the cost of creating a new edit session. I just want to pick a "new edit session" or "open edit session" choice from a menu, with the option to keep my current open files and bookmarks or start fresh, and continue working. Using a new workspace for this every time would quickly result in having many multi-megabyte tag files in varying states of out-datedness, and also mean that if I decided to change the composition of projects in my workspace I would have to make that same update in all the copies of the workspace.

I really think that the set of files open and bookmarks should be separate from the set of projects in a workspace and the tag database for all the files in the workspace. The workspace represents the space of all possible work on a codebase, and the edit session represents the subset of files and locations in those files that are pertinent to the current task. Since I frequently am working on more than one task on a codebase at a time, I want to store the "task state" as an edit session, making it easy and cheap to switch between tasks, and be able to go back to the state of a task that I haven't worked on in a while (e.g. a bug that I thought was fixed but which requires further work or testing).

[jimlangrunner]

I hesitate to post this, as I haven't tried it out yet.  Why not record a macro that closes all open windows and opens a pre-defined set of files?  Were I to try this, I would:
1. Start recording
2. File -> Close All
3. Open files desired
4. Stop recording & save it.
Given a bit of incentive (such as you seem to have), save the files to open (as a file) and adjust the macro read those file names from the saved list.

Such as:

Code: [Select]

#pragma option(strict,on)
#include 'slick.sh'
_command OpenSetOfFiles() name_info(','VSARG2_MACRO|VSARG2_MARK|VSARG2_REQUIRES_MDI_EDITORCTL)
{
   _macro('R',1);
   execute('close-all');
   _SetLanguageOption('xml','xml_wrap','1 1 xml');
   _SetLanguageOption('xml','xml_wrap','1 1 xml');
   _SetLanguageOption('xml','xml_wrap','1 1 xml');
   _SetLanguageOption('xml','xml_wrap','1 1 xml');
   edit('C:\Projects\MICSRating.1.04\UserInterface\rating\modmain.bas');
   edit('C:\Projects\MICSRating.1.04\UserInterface\rating\modrateutil2.bas');
   edit('C:\Projects\MICSRating.1.04\UserInterface\rating\frmquote.frm');
}
Then bind it to a shortcut key or macro button and use it.

Jim

[Clark]

Yep, we need saveable edit sessions.  The rough idea is to allow the user to save the edit session to a file (kinda like vrestores.slk), and then later restore to it. We've had this idea for a while but just haven't gotten to it yet.  In case anyone wants to have a go at it, it's a lot like auto-restore but there's some extra work needed to restore the workspace and files correctly. Also, there's a gotcha with trying to save the edit session when in debug mode.  Easiest thing to do here is just not support it.

[mako]

Regarding Jim's macro suggestion:

The weak point of his procedure is knowing up front which files to include in the macro, and the lack of bookmark saving. What we really need is a macro to dump the current list of open files and bookmarks to a session file in a well-known location. Add another macro that lists all session files in that well known location and allows you to choose which one you want, then reads it and opens all the files and restores the bookmarks in that session file.

This doesn't seem too complicated, but I know nothing about what Slick-C structures hold this information, or file I/O in Slick-C, or how to create the UI elements needed to do this in a user friendly manner.

From Clark's reply, it seems like there might be some subtle wrinkles to getting this to work. But he may be going further than what is really needed. The session file doesn't necessarily need to be coupled to a particular workspace. It just needs to list the open windows, their sizes and locations; the open files; the cursor location within each file; and all the bookmarks. I don't think that info is necessarily coupled with a particular workspace. Whether there is a workspace open (and which one) when the session is saved or loaded seems immaterial. I can easily imagine having an edit session of files I've opened using the file open dialog without having a worspace open at all.

[byates]

Check this thread out for an example of saving and restoring project files...

http://community.slickedit.com/index.php?topic=3346.0

[mako]

Check this thread out for an example of saving and restoring project files...

http://community.slickedit.com/index.php?topic=3346.0

Thanks for the pointer. Associating an edit session with a project is not quite what I want, since I don't want to have to create a new project for every task I work on, but it is a step in the right direction. If I get some free time, I might be able to morph your implementation into a stand-alone edit session save-restore feature.

[Wanderer]

If I get some free time, I might be able to morph your implementation into a stand-alone edit session save-restore feature.

Created two functions to save and restore a 'view':
ccbSaveView()
ccbOpenView()
For example, ccbSaveView("One") creates the file One.vw in the user's config dir.  If One.vw exists, it is overwritten.
ccbOpenView("One") restores the window/buffer configuration saved in One.vw.

byates had done most of the heavy lifting, so I extracted two functions from esdProjectExtensions.e, renamed them, and modified them slightly.
Some cleanup still needs to be done.

Added ccbListViews() -- runs "dir *.vw" in the build window Lists .vw files in a list box for user to select from.

-- Added handler for double-click to select and load view.

[byates]

Nice!  Good work.

[Wanderer]

I think I have sorted out the relative path issues, and the bad xml element problem...

ccbSaveView(_str viewName)
ccbOpenView(_str viewName)
ccbListViews()

Delete any .vw files created with an earlier version.