SlickEdit Product Discussion > SlickEdit®

Macro Programming Interface

(1/3) > >>

dashley:
I really love SlickEdit except for one thing. I am not a big fan of the Slick-C language. It is yet another macro language that I have to learn and I just can not take the amount of time needed out of my day to do it justice.

What I would really like is for the SlickEdit team to publish an API macro interface so that any scripting language could be merged into SlickEdit. This would allow Perl, Python, Ruby or Rexx to be hooked into SlickEdit as a macro language. I believe this would be of interest to a lot of SlickEdit users.

Thanks,
W. David Ashley

ScottW, VP of Dev:
Thanks for the suggestion, W. It gives me a chance to address this common request. We have discussed this quite a bit, but so far we don't have a good solution.

First there is the issue of bindings. Which language(s) do we support? No single scripting language would cover the majority of SlickEdit users, leaving the others to wonder why their favorite wasn't chosen. You didn't list javascript, which would be popular with the Java crowd or vbscript, which might be a favorite for Microsoft developers.

I don't know how we'd do a universal binding that would work for multiple languages, unless it was in C. Ultimately, any other scripting language would need to call the functions we've written in Slick-C because that is what we used to write the API for SlickEdit.

Slick-C isn't just an add-on for customers to automate tasks. A lot of SlickEdit is written in Slick-C. Slick-C gives us many of the benefits of dynamic programming that much of the rest of the programming community is just discovering, but we've had it in SlickEdit all along.

As with many of these languages, the real challenge in learning SlickEdit isn't learning the syntax. Our parameter passing is a little different, but the bulk of it reads like C. The challenge is learning the API. There are thousands of functions you might call when writing something in SlickEdit and finding the right function can often be challenging. Even if you could write macros using a different language, you would still have to learn our API.

Don't get me wrong, we haven't ruled this out. I just want you to understand that this is not as easy as it may sound. I would appreciate any ideas you have on how we might tackle this. I'm hoping we'll have some time to experiment with this before too long.

--Scott (Wet Blanket) Westfall :'(

soumik:
Is there any place I can get the complete list of all the Slick-C calls? On several occasions, I have written functions myself only to find out that something similar exists.

garion911:
Maybe you guys could do something simple.. A generic C "call slick-c method"..

* Disclaimer: I don't know Slick-C. but I think you will get the idea.

I envision a header file that would define the various datatypes that can be returned by slick-c functions.

typedef SLICK_VALUE { int type; int size; char *data };
#define SLICK_INT_TYPE 1
typedef SLICK_INT {.. };
#define SLICK_FLOAT_TYPE 2
typedef SLICK_FLOAT {..};
#define SLICK_LIST_TYPE 3
typedef SLICK_LIST {};
and so on..

Then have a single "execute" command:

SLICK_VALUE execute( char *slickcommand, ...);

Then devs can wrap that execute command into the language of their choice... It wouldn't be perfect, but it would be a start.. I think I could wrap something like that for Python in a matter of hours.. I'm sure others could do Perl, Lisp, Php, 6502 assembly langauge  ;D

I'm sure someone could donate some space to holding the various bindings (some user-contrib space on slickedit.com?)..

Graeme:

--- Quote from: garion911 on September 08, 2006, 06:46:00 AM ---Maybe you guys could do something simple.. A generic C "call slick-c method"..

* Disclaimer: I don't know Slick-C. but I think you will get the idea.

I envision a header file that would define the various datatypes that can be returned by slick-c functions.

typedef SLICK_VALUE { int type; int size; char *data };
#define SLICK_INT_TYPE 1
typedef SLICK_INT {.. };
#define SLICK_FLOAT_TYPE 2
typedef SLICK_FLOAT {..};
#define SLICK_LIST_TYPE 3
typedef SLICK_LIST {};
and so on..

Then have a single "execute" command:

SLICK_VALUE execute( char *slickcommand, ...);

Then devs can wrap that execute command into the language of their choice... It wouldn't be perfect, but it would be a start.. I think I could wrap something like that for Python in a matter of hours.. I'm sure others could do Perl, Lisp, Php, 6502 assembly langauge  ;D

I'm sure someone could donate some space to holding the various bindings (some user-contrib space on slickedit.com?)..


--- End quote ---

You mention "header file" and generic "C" but your typedefs aren't valid C code ??

Where would the Python interpreter live?
How would you handle calling conventions  (i.e. parameter ordering, stack cleanup) and data layout?

Slick already has a dll interface (for Windows) and an API consisting of several hundred functions (names start with vs), though I don't see any info on calling conventions or which C compilers are likely to work.

Graeme

Navigation

[0] Message Index

[#] Next page