Hi Rob, I'll try to be as helpful as I can

.
1.) Whats the best way to store/load language definitions?
1a.) Can I just place these in user.vlx, or should i write a script to add extensions and to populate this file?
1b.) Whats the best way to modify these scripts/files using a transparent update strategy?
You should probably look at either
fortran.e or
modula.e as examples. These files are both really good starting points for adding custom language support. Basically for one of your languages, you are going to want to create a similar macro file, which calls
create_ext in the
defload function. You can also define your lexer in LANGUAGE_NAME.vlx, and load this in the
defload function of your macro file by calling
cload. That way, when your language support macro is loaded into the editor, so is the lexer, and you are good to go.
Now to distribute your custom macro files and custom lexer files to your developers once they have Core installed, you have a couple options. You could of course have your developers download and load all of your custom macro files, and then they would be set. This is the probably the easiest. The other option is to use the hotfix mechanism of SlickEdit which was introduced in the v12 timeline (Core 3.3.0 is based off SlickEdit 12.0.3). This mechanism was never exposed in Core, but the functionality is still there. So you could create a hotfix zip file containing all of your custom macros, have your developers download this and then load it via the
load_hotfix command. Creating a hotfix file will be a little bit of work, but we could provide you directions on how to do so.
If you explain more specifically what you are getting at in 1b I might be able to help you out there...
2.) Is there any recommended way to maintain a project structure for Slick-C macros. I see a primarily flat structure in SlickEdit itself, but perhaps there are some other ways to do things.
For working on your Slick-C macros, you will probably want to create an Eclipse workspace for your Slick-C code, and then you can organize this however you want. But no, there is no recommended way to maintain a structure for Slick-C macros...at least not on the v12 base. In v13 we have Object Oriented aspects incorporated into Slick-C like classes, inheritance...so we have a much different structure for our code.
3.) How much of eclipse is accessible through Slick-C macros? I have already been able to access the outline view very cleanly. How about external tool integration(Compilers) accessing things like the problem view or equivalent.
We don't really have APIs for accessing Eclipse views through Slick-C macros

. You can access the Outline view through Slick-C because that is basically the SlickEdit defs tab dumped into the Outline view

. You will (of course) be able to access any of the other SlickEdit views through Slick-C, but you won't be able to directly influence something like the Problems view from Slick-C code.
Now, the Problems view
is supported by Core, meaning that the Problems view will still be populated in Eclipse just as it would without Core, and clicking on a problem will bring you to the appropriate position in a SlickEdit editor, etc.
I hope this helps at least a little bit...let me know if you have any follow-ups.
- Ryan