vslick.sta - convert to text format?

[tcolgan001]

Is there any way to get a version of vslick.sta in text (perhaps xml) form?

It would be nice to be able to diff a configuration to a previous one.

[StephenW]

I second that.  I have had a number of problems over the years that have necessitated deleting the vslick.sta file.  It would have been nice to have been able to work out what was going wrong and maybe fix it.

[hs2]

IIRC vslick.sta/stu contains compiled macro modules. So kind of Slick-C (R) decompiler would be needed...
HS2

[StephenW]

You could just do a dump that displayed the name of the macros (and hopefully their timestamp) and left it at that.  Decompiling is not necessary, as the source of everything that is in vslick.sta should be available.  For macro variables, you would want a dump of the values.

BTW What is vslick.stu?  I do not seem to have one of them.

[hs2]

Right - almost everything is there in source but it's non-trivial / costly to recover once vslick.sta was corrupted.
Hence I run a backup on regular basis (quite often). So it's not a big deal to undo some heavily broken .. customizations
For some reason 'vslick.stu' is the UNIX version of 'vslick.sta' on Windows.
HS2

[tcolgan001]

Getting back to a working copy is only one purpose of a text/xml configuration file.

Another is the ability to merge portions from different configurations. Or perhaps manually edit lists, menus, etc. 

I see this one of SlickEdits major shortcomings (Codewright has text configuration files).

Why can't the inputs which generate the .sta file also be saved in an text/xml file?

[Dennis]

Back to the original question.  The majority of your configuration is reflected in vusrdefs.e (vunxdefs.e on Unix).  Comparing this Slick-C batch macro is an effective way of "diffing" a configuration.  And, if you open vusrdefs.e in the editor, and bring up backup history, OMG, there are your previous configuration versions.

For the uninitiated:  vusrdefs.e is a Slick-C batch macro.  This means, that if you modify it, you will need to run it in order to have the changes take effect.

In the future, we want to separate storage of configuration settings from the state file -- this will allow us to keep settings in text/xml file.  You have to understand how far back this design dates to understand why it was necessary.  Reading one binary file, and just sweeping the interpreter state into memory gave us much faster startup times than parsing large text files.  That was back in the day when 20 more Mhz seemed like a bundle of speed, and disk drives came in M's not G's. 

So, understand that we have this on our road map, but there are bigger fish to fry first.

[Lisa]

For some reason 'vslick.stu' is the UNIX version of 'vslick.sta' on Windows.
HS2

I know this one! Because the Windows state file is not compatible with UNIX and vice versa, they were given different extensions so the difference is clearly visible.

I DO pay attention in those boring architecture meetings 

[StephenW]

I think that means you can run a Unix and a Windows version out of the same directory structure (with at least one of those using network access).

[pbrown]

I'm also strongly in favor of using text as an interchange format for syncing SlickEdit configurations between systems. 

The best thing that I could come up with is something exploiting the behavior Dennis describes above.  My sync tool checks various files from my SlickEdit config directory into Perforce (SCC).  I have a "syncdata" Perl script that brings up a directory-wise comparison tool to compare the checked-in "official" configuration and my current system's configuration.  I bring up the files I care the most about (e.g., vusrdefs.e, vusrmacs.e for my macros) in these tools and copy lines from one side to the other -- basically selectively copying settings.  I don't do a full sync because I don't want to sync some of the system-specific stuff stored in vusrdefs.e (recent files, tool window settings).  After doing whatever updates I want in either direction, I check in the new "official" configuration and run the following command to update the vslick.sta in my profile:

  vs.exe -#vusrdefs "-#unload vusrmacs.ex" "-#load path/to/file/vusrmacs.e" -#save_config -#safe_exit

This brings up a SlickEdit window, merges in the new definitions and macros from my profile directory, saves the result, and exits.

There are a couple screwy things with this setup:

- There seems to be little rhyme or reason to the order in which settings are saved to vusrdefs.e.  After some configuration changes, it seems that different config lines "jump" relative to my last "official" version.

- Ideally, I'd love the ability to be able to factor settings out better (i.e., not save tool settings and recent files in the same file with key bindings and top-level options).  At one time, my C alias file is on the line above my basic settings for html files, and then some time later, it's 11 lines down.

- It would be good if you could have some settings be per-workspace.  I'm struggling now with having multiple projects of vastly different kinds (e.g., some C code, some containing mostly text files) that "want" different toolbar settings.  As far as I can tell, my choices are to either live with sub-optimal settings for some projects or fork off multiple config directories.  The latter choice means that I'd have to use the same hack to keep my key bindings/macros in sync.

Pat