Macro Programming Interface

[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 

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

[Graeme]

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 

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

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

[Graeme]

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.

My mistake.  The simple example says Visual C++ for Windows and GNU C for Linux !!

Graeme

[garion911]

Thats probably why I had no clue about an API... I don't have windows.. I see refernce to it in the docs, but nothing in my slick directories..(though I found a bunch of headerfiles in sysconfig/vsparser, but they look more like configuration than exporting Slick stuff.)

If there's a library and headers files we can link under OSX (or Linux, though its no longer my primary system), could someone tell me? I could start on a basic Python wrapper in short order.

(as for the comment on my 'invalid typedef's', it was only pseudo code, not meant for compilation..)

[dashley]

Here is my suggestion. It will not be as easy to implement as it sounds, but it will make it VERY easy to implement from any scripting language.

There should be onyl one API. It should look something like this (in C):

char * vsmacro(char* cmd_string);

SlickEdit should be responsible for the interpretation of the command string and translating it into the appropriate Slick-C calls. The function should return a single character string with the results of the command execution. It is obvious that this will not be easy to implement from the SlickEdit perspective. Essentually a new command language will need to be developed or Slick-C itself will need to be extended. All of that is a lot of work. But the advantage is a really easy API that any language can be hooked into.

Another mechanism that is required is the API for invoking the script language interpreter. This could be implemented as a DLL/SO and a configuration option dialog to set it up. SlickEdit only needs to define the calling interface for the interpreter and the sDLL/SO would then actually implement that function.

Comments are welcome.

Thanks,
W. David Ashley

[ScottW, VP of Dev]

Excellent ideas. I love this kind of discussion. I've been leaning towards the single function interface, myself, a kind of thunk. I'd favor using two arguments like,
                      callSlick("function_name", "argument_list")

Of course, we still have to figure out how to do this. 

Though this may solve the issue for calling and passing parameters, we still would have a lot of work on event handling. For example, Slick-C uses the notation "_command" to denote functions that can be used from the command line or be bound to a key sequence. We'd have to determine a way to preserve this kind of functionality. Key bindings are the key to being efficient with an editor!

--Scott

Keep those ideas coming, and we'll see what we can do.

--Scott

[Graeme]

It would also be useful if it was possible to use C++ and a full blown GUI library (cross platform or otherwise) such as wxWidgets to create a window that could be docked in the IDE.  I know there are GUI libraries such as TK that work with Python but last I looked it's pretty limited  - but even with this, it would be nice if a GUI interface could be developed in the "third party language" and function as part of the Slickedit app.  A C++ app running in a dll doesn't have the protection that the slickedit macro interpreter gives (e.g. detection of uninitialised variables or array index out of range) that protect against slick crashing - but maybe slick could catch exceptions coming from the dll and terminate it.  This could be the users own risk anyway.  It's definitely a great feature that you can develop slickedit macros within slickedit without crashing the editor.

How would the third party language access properties such as p_buffer_name and how would callbacks (such as needed for for-each-buffer or call-list) work I wonder.

Graeme
 

[garion911]

For events I would do something like this.. Psuedo code (python and c mixed for fun):

// Wrapper code
int registerCallback( char *eventName, void *funcPointer )
{
    // register the eventname with Slick
    regsiterEvent( eventName, eventHandler );
 
   // Add the function to our list of handled functions
   funcs[ eventName ] = funcPointer;
}

void eventHandler( char *eventName, char *eventData )
{
    // is this an event that we're handling - sanity
    if eventName in func.keys()
    {
        // handle the event
        funcs[eventName](eventData);
    }
}

And its a standard that we need to add a _ in front, the code can handle that automaticly..