Message-Id: Date: Mon, 10 Apr 2000 09:47:28 +0200 To: applescript@barefeetware.com From: Peter Hartmann Subject: editor opinion Cc: Emmanuel When comparing Smile with other script editors I think there are two points that cannot be stressed enough: (1) There are huge conceptual differences between debugging with Smile, ScriptEditor and ScriptDebugger/Scripter. In Smile you absolutely have to use text windows to execute blocks or single lines of a script to see if they work as expected. You then group these blocks/lines in handlers and compile them to persistent objects. In fact values in variables and compiled handlers are persistent in text windows. So once compiled you can (re)use them any time you like. So, if you compare Smile to other script editors you get something like the following picture: In ScriptEditor, when the script goes thru a loop, all you can do is open the event log and wait possibly thru the execution of endless loops watching heaps of uninteresting data pass thru the window (which only displays a limited amount of data, so things from the beginning will get rolled over at some point). There is no way to change values other than changing the script to produce different values, no possibility to examine values during execution, no single step execution. In ScriptDebugger/Scripter it is possible to halt execution of a loop using break points and set variables to new values. But still, if you stop script execution once and change the script somehow, you have to execute the script from the beginning to get to the point where the problems are supposed to start. And you can not replace handler implementation A by implementation B during script execution. You have to stop, comment handler A out, uncomment handler B, and restart execution again, going thru variable initialisation again, which will in turn force you to reset variables to the state of the script you actually want to examine. In Smile (and I think this is what is not really obvious to newcomers) since variables are persistent in text windows you can easily (re-)set/reuse your variables by executing the line "set myVariable to "something" somwhere in the window) and execute only those lines that appear to cause trouble. When executing loops you can use log(myVariable) to see what is going on during the execution of a loop. (Use "display" to coerce an arbitrary value to text.) So you may use logging where appropriate but just only watch the variables you are interested in. To use handler implementation B, just select it and hit enter. In Smile's text windows there is no notion of a script execution cycle. Everything is just single lines (or even parts of single lines, or just an arbitrary selection of code, if it does make sense) and persistent variables and handlers. No fiddeling with floating windows, no resetting of variables to the same value over and over again, no commenting or uncommenting, no stopping and restarting from zero. And no copying and pasting if you want to test only the result the innermost bracket of a nested expression. Just select it and hit enter. I admit that I didn't like this concept of Smile for debugging very much in the beginning, but the more I use it, the more I realize how powerful it really is. So if you are not willing to embrace Smile's unique and in fact very simple concept of debugging, but cling to what you may be used to in CodeWarrior (or other IDEs or ScriptEditors for that matter), you'll never be able to use Smile effectivly, and then, of course, you'll dislike it. (2) Smile is much more than a simple script editors. Though admittedly underdocumented at the moment, it also is a script execution environment providing a sophisticated GUI for AppleScript, and a scriptable styled text editor, that also can display PICTs. That's three in one. So a comparison of Smile with other script editors will inevitably force you to refer to Smile's script editing facilities only, since all the other script editors are just only script editors. __Peter Hartmann ________ mailto:hphartmann@arcormail.de