New Editor Features: Syntax Highlighting, Parameter Help, Syntax Checking, Automatic Code Reformatting

The script editors now support syntax highlighting. Essentially, this means that recognized names of commands, functions and keywords are highlighted with different colors. Also, the software displays some things such as comments and string constants differently. That way, one can more easily recognize the structure of script code. The following screenshot from one of the demo scripts of RP Fiber Power serves as an example:

This is surely very useful, but it also looks nice, doesn't it?

The script language of our software supports many functions, and it can sometimes be difficult to remember the exact list of parameters needed for each function. I have been able to implement a very nice solution for that. If you use such a function, just type its name followed by the opening parenthesis into the editor, and you will get the parameter help displayed; you can also later on click on a function parameter to get this:

If you have once used such a function, the displayed parameter names will easily remind you of what needs to be entered there. In many cases, you won't need to use the interactive help system any more. That's certainly nice, although the interactive help system, showing you many more details, is also rather nice to use: just place the cursor on a function name, for example, and press F2 to search for the function name. Then confirm your choice by double-clicking on the function name in order to get the full explanations displayed.

Although simulation scripts usually run rather fast, there are some cases where computation times are substantial – for example, when doing numerical beam propagation on a large numerical grid. In such a case it can be quite awkward if the program executes such a script and then runs into a syntax error caused by a trivial typo, for example. You may then have to execute the whole script once more after correcting the error. Therefore, it can be desirable to check the correctness of the syntax before actually executing a script.

Exactly that has now been provided: with Edit | Check syntax or with Ctrl-H you will get the syntax quickly checked. In case that a problem is found, the cursor is moved to the corresponding position, and an error message is displayed. In the following example case, a closing parenthesis was missing:

As explained in my recent post, I have introduced improved code formatting rules, which make the code substantially more readable. Although that is nice, a rather awkward problem is encountered if you (like myself, for example!) already have many scripts, which you would then like to have reformatted. Well, the software still accepts the old formatting, but it is not nice to have all scripts which do not fit to the improved formatting rules.

I myself originally started to manually reformat manuscripts, and I can tell you, that can drive you nuts! That triggered the idea that automatic reformatting would be very nice to have. The caveat is just that it is also rather difficult to implement it. Nevertheless, I finally did this – spending many days with really hard brain work. Now, I'm very delighted to have got it working very nicely.

As an example, I had a script containing the following part:

R_min:=150 mm { minimum curvature radius }
L_bend:=R_min*(90 deg)
show "L_bend: ", L_bend:d3:"m"
z1_bend:=(L_f-L_bend)/2
z2_bend:=(L_f+L_bend)/2
R(z):=
  if z < z1_bend then
    0
  else if z < z2_bend then
    R_min
  else
    0
theta(z):=
  if z < z1_bend then
    0
  else if z < z2_bend then
    -(z - z1_bend)/R_min
  else
   -pi/2

I just pressed Ctrl-R in the editor, and thereafter it read as follows:

R_min := 150 mm { minimum curvature radius }
L_bend := R_min * (90 deg)
show "L_bend: ", L_bend:d3:"m"
z1_bend := (L_f - L_bend) / 2
z2_bend := (L_f + L_bend) / 2
R(z) :=
  if z < z1_bend then
    0
  else if z < z2_bend then
    R_min
  else
    0
theta(z) :=
  if z < z1_bend then
    0
  else if z < z2_bend then
    -(z - z1_bend) / R_min
  else
    -pi / 2

If you wonder how such a feature can be implemented, I give you a few hints. When starting up, the software reads a formal definition of the whole script language in the form of a text. The resulting data in memory can later be used by a script parser. Its original function was syntax checking (see above), but the mentioned formal definition has been amended such that it also describes the preferred kind of formatting – for example, at which positions in the code we like to have a single blank, where do we need to have a line break, or at which locations we will keep a line break only if there was already one in the original code, etc. The mentioned parser can then output the correctly formatted code when reading the original code. It is a highly recursive operation, particularly in the context of mathematical expressions. As you can probably imagine, it takes a lot of thought even just to design the above-mentioned formal description of the script language (particularly if it is so powerful and versatile as ours), let alone to implement the parser which can then operate on script code accordingly.

Surely, the new features will be attractive for people considering to start with our software. Existing users will soon get upgrade offers – as always, being very fair; the upgrade prices are only a little higher than the difference of the license prices.