Slick-C Language Enhancements

[Graeme]

Dennis

jszakmeister said

I've been using SE for nearly 6 years, and I've barely touched the Slick-C facility precisely because I can't find documentation on the function or naming convention I need to follow, and I don't have time to spend hours searching through the code base only to find a fragile solution that breaks between releases.

I am wondering how much of an issue there is relating to "a solution that breaks between releases".  What is the likelihood of end user slick C macro code not working with a new release of Slick C?  Does slickteam try hard to keep backwards compatibility?  Are you more likely to have code that breaks with a new release if you call non-command non-documented functions? 

I guess it's impossible for slickteam to document all of the changes to the published SlickC code that might break end user code, but normally you'd expect changes made to an API to be documented with a new release.  I guess the "deeper" you go in using the published slick C code, the more likely your code is to break, but there's not really a clean boundary as there is with most APIs.

For example, in my GFileman toolbar, I wrote some code to put the focus in an edit control on the toolbar from a command, but first I needed to make the toolbar visible, so I copied some slick C code that calls _find_formobj then _tbIsVisible, then _tbMaybeAutoShow, then tbShow, then activate_toolbar.  This seems to be at a fairly low level (so I won't be surprised if it breaks one day) but is doing a fairly high level operation.

Graeme

[jszakmeister]

jszakmeister

Let me address a few of your comments.

The Note was simply to avoid a language war and to keep everyone focused on the fact the thread was about Slick-C, not integrating a different language.

Your frustrations with the current state of Slick-C seem to be focused more on the API's and docs than the actual language.  We are improving the docs, and the API's will follow eventually.  Note, that if we transported our existing API's to any other language, they would still be what they are.

You are correct, most of my frustration does stem from the documentation than anything else.  I simply do not know what tools are available to me, and how to use them.  The current documentation has improved but is still far from adequate, IMHO.  I'm not trying to knock you guys.  I really want to see SE improve in the macro arena, because it stands to make the most productivity gain for me and guys on my team.

However, I do have so issues with the API.  I find it very difficult to (what I would call) simple operations.  For instance, I'd like to see 'svn blame' in an editor window.  Looking at the docs, I haven't the slightest clue how to lauch the call, grab the output, create a new editor window, and insert the captured text into it.  Furthermore, I *always* have to resort to scrounging through the included macro code to find an example of what I'm looking for.  At that point, I don't know if I'm making use of a public or private API.  If the only API I can count on being public are the ones that are documented, then I feel the current (public) API is too shallow to do something useful in a reasonable amount of time.

FWIW, my concern is more towards getting the job done, and what I (as a user) really desires is a toolbox that has a reliable, and stable set of tools that I can leverage.  I haven't found that with the current Slick-C API.  I suggested Python in a different thread, partially because it's a language that I know well.  I'd take just about any language as long as it's easy to use, and has an adequate toolbox.  In my case, Python fills that gap, which is why I have suggested it.  I think Slick-C trying to provide a fraction of what's available in many of these other high-level languages is unacheivable.

I guess it's impossible for slickteam to document all of the changes to the published SlickC code that might break end user code, but normally you'd expect changes made to an API to be documented with a new release.  I guess the "deeper" you go in using the published slick C code, the more likely your code is to break, but there's not really a clean boundary as there is with most APIs.

Well stated.

Dennis, if you'd like to talk about this more, we can probably save some time by chatting over the phone.  You guys should have my number on record.  I really do feel like I'm missing out on a very important part of SlickEdit.

-John

[todd_s02]

I have to agree with alot of what jszakmeister says.  I love slickedit..  been using it since version 5 and my company has had no problems upgrading us to every new release.  But, every time I go to write a macro, I end up spending hours trying to find the functions to do what I need.  Often, there's several that seem to do the same thing.  To be honest, I haven't even tried for the past couple of releases.  But my experience has been that Slick-C always seemed like the most powerful feature of the editor, but somewhat crippled by the difficulty to actually use it.  It's always felt like a dozen developers hacked together various functions in Slick-C and someone came along and said "hey, cool!  let's make these accessible to our customers".  Yes, if I spent a few hours I could write a really cool macro that saves me time.  However, it's hard to justify writing a macro to save 2 hours, when the macro takes 8 hours to write.

Just glancing through the Help file, the problem is apparent -  "number2yesno", "strip_last_word", "_file_date", "_CheckLineLengths".  There's no consistency, no way to "guess" what the function would be called, etc.  Looking at the help for VS2007, the debug functions are nice Consistently named, the names more or less describe exactly what they do, and I feel like I could quickly find what I need.  I think the best thing you could do to Slick-C is redo all of the public functions and make nice, clean APIs like this.  I've looked around from time to time, and I've never really found slickedit macros on the net.  I've always wondered why that was - either people wrote really cool macros and never shared them (or I just suck at finding them), or the learning curve was so high most people didn't bother.

[ScottW, VP of Dev]

I agree with much of what's been written. We are working hard to revise the Slick-C Programming Guide. As part of that, we plan to add more meaningful examples that should help with common tasks.

The API is a whole other issue. The Help system should help you find functions using the categories. Select Help > Contents and expand the "Macro Functions by Category" topic at the bottom. Certainly the names could be improved in many cases, but renaming functions would lead to far more breakage. Perhaps we need a deprecation mechanism that allows us to mark functions for future deletion. Then when a macro is loaded we could display a warning for any deprecated functions.

I'll talk to the team and see what we can come up with. One thing to keep in mind about Slick-C is that it was created before most of the languages that people suggest we use instead, like Python. It was created for many of the same reasons, to provide the SlickEdit development team with the benefits of a dynamic language and speed development.

Replacing Slick-C won't really provide a boost in productivity for those who write macros. As these posts prove, it's not the language that causes difficulty; it's the API. Though many of these languages have rich APIs for various tasks, none offer a standard API for Window, Buffer, Text, etc. manipulation.

--Scott

[rbbyrbsn]

since the default access is public what kind of access will protected provide? package only like Java's default or packages and subclasses of package members?

[MindprisM]

Actionscript 3 features I like:

========================

First class citizen of XML var type, note quoteless inline - example:

Xml xml=<GALLERY>
<IMAGE TITLE="school">image1.jpg</IMAGE>
<IMAGE TITLE="garden">image2.jpg</IMAGE>
<IMAGE TITLE="shop">image3.jpg</IMAGE>
</GALLERY>;

trace(xml.IMAGE);

(prints)
<IMAGE TITLE="school">image1.jpg</IMAGE>
<IMAGE TITLE="garden">image2.jpg</IMAGE>
<IMAGE TITLE="shop">image3.jpg</IMAGE>

trace(xml.IMAGE[0]);

(prints)
image1.jpg


trace(myXML.IMAGE.@TITLE);

(prints)
schoolgardenshop

trace(myXML.IMAGE[0].@TITLE);

(prints)
school

==============================

Data Binding:

[Bindable]
var Bound:String="I am Bound";

[Bindable]
var Bound2:String="I am Bound2";



Xml xml=<GALLERY>
<IMAGE TITLE="school">{Bound}</IMAGE>
<IMAGE TITLE="{Bound2}">image2.jpg</IMAGE>
<IMAGE TITLE="shop">image3.jpg</IMAGE>
</GALLERY>;


trace(xml.IMAGE[0]);
(prints)
I am Bound

trace(xml.IMAGE[0]@TITLE);
(prints)
I am Bound2


...elsewhere in code...

Bound="Bound Changed"


trace(xml.IMAGE[0]);
(prints)
Bound Changed

========================

Also would like to see:

typeless h:[];

h.Construct("{a:1,b:'str',c:{'contents'},d:[1,'str',true]}");


trace(h.ToString());
(prints)
{a:1,b:'str',c:{'contents'},d:[1,'str',true]}

trace(h.Access('a'));
(prints)
1

trace(h.Access('c'));
(prints)
{'contents'}

trace(h.Access('c{}'));
(prints)
contents

trace(h.Access('d.0'));
(prints)
1

trace(h.Access('d.99','not there'));
(prints)
not there


h.Push('z.y.x','xyz');
trace(h.Access('z.y.x'));
(prints)
xyz


OR haha, just give us mutable objects like javascript.

[MindprisM]

to make the Slick-C compiler smart enough so that when user asks to compile/load a given Slick-C file ('MyMacros.e'), the Slick-C compiler will NOT blindly use the 'MyDefines.ex' of 'MyDefines.e', but rather - first compare 'MyDefines.ex' and 'MyDefines.e', so that if 'MyDefines.e' is newer (since it has been modified too) - it will first compile/load it (as well as any other stale included files, if there are any), and only then compile/load 'MyMacros.e'.

I am using a hack to do that kind of dependency loading, it kind of looks like this:

In each file is the do-it-by-hand part:

Code: [Select]

// maintain this by watching your calls
 _str __array_depends[]={"__hash","__msg","__file"};
 //#LOCALS_

//#INIT
 definit()
  {

     array_refill(__array_depends,"__hash,__msg,__file");
    load_modules("__array");
  }


Then in a root primitive file:

Code: [Select]

int load_modules(a)
{
   if (arg()==0) {return (0);}
   //dep=null;
   f=1;

   //_message_box(a._varformat());
   //Msg(a._varformat());
   if (a._varformat()==VF_EMPTY||a._varformat()==VF_ARRAY) {
      dep=a;
      //_message_box(dep._varformat());
      f=0;
   }
   if (a._varformat()==VF_LSTR) {
      //Msg('load_modules:1');
      i=find_index(a '_depends',VAR_TYPE);
      if (!i) {return (0);}
      //Msg('load_modules:2');
      dep=_get_var(i);
      //Msg(array2str(dep));
      f=0;
   }
   if (f) {return (0);}
   for (x=0;x<dep._length();x++) {
      //_message_box(dep._el(x));
      if (1) {
         i=find_index(dep._el(x) '.ex',MODULE_TYPE);
         if (i==0) {
            //_message_box('loading:' dep._el(x));
            if (dep._el(x)!="") {
               load(SLICKEDITMACRODIR dep._el(x) '.e');
            }
         }
      }
   }
   return (0);
}

This insures dependencies are loaded, and could be altered to recompile and load.