The ICore Script IDE — writing, running, debugging and fixing .icore scripts#

A script is a text file with the extension .icore that holds lines you could type at the command window (The command window — the command engine for a user): assignments, expressions, commands, recipe statements, and blocks such as for … end and function … end that span several lines. The ICore Script IDE (called the Script Runner before 2026-09-23) is the window where you write scripts, run them and fix what stops them. It opens from the left panel's Script IDE button, or from Code Engine ▸ Scripting ▸ ICore Script IDE. Every script it runs lives in the scripts folder of the open project, and its navigator shows that whole project folder.

The window#

Showing and hiding panels#

The navigator and the four panels (Output, Problems, Variables, and Call Stack and Watches) can each be hidden. Hide one with the × on its title row, or with its button on the panel bar at the window's right edge. Bring it back with the same button, or from View ▸ Panels, which lists every panel with a tick beside the ones that are showing and ends with Show All Panels. A panel's button is lit while the panel is showing, including while it is in a window of its own. When all four bottom panes are hidden, the editor takes the whole height, and showing one of them brings back that pane alone, across the whole width. A hidden panel's space goes to its neighbour, and it comes back at the size it had. A hidden panel leaves no edge behind, so no drag can bring it back by mistake; dragging a panel's edge until the panel has no room left hides it, as its × does. The navigator works the same way. Which panels are hidden is remembered per project.

Docking panels beside the code#

The four panels start side by side under the editor. Each can dock to the left of the code (between the navigator and the editor), to its right, or back under it. Drag the panel by its title bar: the dotted grip, its name, or anywhere along the bar that is not one of its buttons. While you drag, the window shows in the accent colour where the panel will go:

• near the code's left or right edge, a column beside the code;
• near its bottom edge, a strip under it;
• over panels already docked on a side, that side, with a line where the panel will go in among them.

Let go and the panel docks there, with everything it held. Panels on the same side share it: side by side under the code, one above another beside it. Drag the edge between two panels to share the space differently. A side with no panels showing gives its space back to the code, edge and all. If you let go over the middle of the code, the panel stays where it was.

Secondary editor windows (see Secondary editor windows) dock panels the same way. Drag a panel's title over one of them and it docks around that window's code. It keeps working there: a run still writes to Output wherever it is. When you dock that window's scripts back or close it, its panels come back to the IDE on the same side.

Where each panel is docked is remembered per project, along with the sizes.

Output comes back whenever a script runs (Run, Run Line, Run Selection, Run to Cursor, Run All, Debug, or Run in a secondary window), because the run writes there. It comes back where it is docked, and only Output: the other panels stay as you left them.

Output, Problems, Variables and Call Stack and Watches can also each live in a window of their own. Drag a panel by its title off the IDE's window and let go, or press ↗ on its title row, or double-click its title. The panel opens in its own window where you let go, with everything it held, and it keeps working there: a run still writes to Output, and a paused run still fills the call stack. Its space in the IDE goes to its neighbours. To dock it back, drag its title over the IDE and let go (near an edge of the code to choose the side), press ↙, double-click its title, or close its window. Hiding a floating panel with its × docks it and hides it. View ▸ Dock All Windows docks every panel and script window, and closing the IDE docks them too. The navigator stays in the IDE.

Secondary editor windows#

Drag a script's tab off the tab strip, a little way above or below it, and let go: the script opens in a window of its own. You can let go anywhere, even over the IDE's own editor, and the new window opens where you let go. The tab fades once it is far enough from the strip, and drags back into a reorder if you return to the strip before letting go. The new window holds the script, with its unsaved edits, its caret line and its breakpoints. It has Run, Debug and Save for its script, and Dock to put it back. View ▸ Move Tab to New Window does the same without a drag.

• Drop a tab onto another secondary window's tabs to move it there.
• Drop a secondary window's tab anywhere over the IDE, or press Dock, to bring it back as a tab.
• Closing a secondary window docks its scripts back; it never closes a script. View ▸ Dock All Windows docks every one. Closing the IDE docks them too.
• A script in a secondary window is still one of the IDE's scripts. Save All and every run save it. Its problems and a run's output land in the IDE. A paused run shows its line in whichever window holds the script. Picking it in the navigator brings its window forward.
• An open secondary window's scripts are remembered as open tabs, and they come back docked the next time the window opens.

Scripts in folders#

Scripts can live in subfolders of scripts. A script's name then includes its folder, as in tools/fit.icore. That is the name its tab shows, and the name run takes: run tools/fit. Renaming a script or a folder moves its open tabs, breakpoints and remembered caret line with it.

Running a script#

Run runs the open script from the top. It is the same run that run <name> performs at the command window (The command window — the command engine for a user), in the same workspace:

• the functions a script defines are ready before its first line runs, so they may sit at the end of the file, where MATLAB puts them;
• a block runs as a whole once its end arrives;
• return ends the script successfully;
• the first line that fails stops the run.

The status bar then reads ✓ Ran 12 line(s) or ✗ Stopped at main.icore:5.

When a run fails, the place it names is the statement that failed, not the line that closed its block. If the statement is inside a function, or inside another script started with run, the failure names that file and line, and the output lists the chain of calls that led there. The failure also goes to the top of Problems, and clicking it opens the right file at the right line.

Run Line (or F9) runs just the caret's line, in the same workspace and without saving — useful for checking one statement. On the first line of a block (for, if, while, switch, try, function) it runs the whole block through its end, because the opening line alone cannot run. Failures still report the script's own line numbers.

With text selected, F9 (and Run ▸ Run Selection) runs exactly what is selected instead: part of a line such as a + 2, or several whole lines. Line numbers count from the line the selection starts on.

Run saves the open script first, so what runs is what you see (see Files on disk below). Run Line does not save.

The output and the prompt#

Every line in Output remembers where it came from. Click one to open that place in the editor:

• an echoed line opens the line it echoes;
• a line printed by a function opens the line in that function that printed it, even when the function lives in another script;
• a line that names a place, such as setup.icore:12: from a failed run, opens that place.

Errors only hides everything but failures and the run banners. Copy copies the lines shown, and Clear empties the pane.

A ; at the end of a statement hides its value, as in MATLAB. It does not hide what the statement prints: disp(x);, fprintf(...); and f(); all still print.

The prompt under the output runs one line at a time in the same workspace as a run. It has the command window's history (Up and Down) and completion (Tab). A block you start there is held until its end, and Escape drops it without running it. What it prints lands in Output, and Variables updates after each line.

Writing a script#

While the caret is inside a call, a line under the editor shows what the call takes. The argument you are typing is in bold, and the name's description follows it. For example:

lsim(sys, u, t) — Simulate a model's response to an input

A function the script defines itself shows its own inputs and outputs.

The editor lays out blocks as you type:

• Enter after a line that opens a block, or after an arm (else, elseif, case, otherwise, catch), indents the next line one level.
• A line starting with end or an arm keyword moves to its block's column when you press Enter on it. This happens on Enter rather than while you type, so a name such as ending is never pulled left partway through.
• Ctrl+I re-indents the whole script, four spaces per level. A switch puts its case lines one level in and their bodies two.

Names the console recognizes are coloured by kind. The theme's blue is for the language's keywords (for, if, end, function), teal for commands (disp, fprintf, whos, clc), pink for the diagram's recipe verbs, and gold for math and control functions (sin, linspace, tf). Strings, numbers and comments have their own colours, and a name bound to a diagram object (a handle) is green. Each line has a little room above and below its text, and the line numbers are set in the same font and size as the code. The colours update as you type. The list of matching names opens as you type a name, and narrows with each letter.

Brackets and quotes pair up:

• Typing (, [, { or " before a space, a closing bracket or the end of the line inserts its partner too, with the caret in between.
• Typing the closer when it is already next steps over it rather than doubling it.
• In front of a name, ( inserts only itself, since it opens a call.
• A single quote ' is never paired, because x' is a transpose.
• With the caret beside a bracket, that bracket and its partner are highlighted. A bracket with no partner is highlighted in red.
• Brackets inside a "…" string or a comment don't count.

Comments follow the command window's rules:

• # comments out a whole line (it must be the first character).
• % comments out the rest of a line, unless it sits inside brackets: setText(50% done) keeps its text.
• %{ and %}, each alone on its own line, comment out everything between them.
• Ctrl+/ comments the caret's line out with # , or back in. A line commented with % can be uncommented this way too. With several lines selected it decides once for all of them: if every line is already a comment they are all uncommented, otherwise they are all commented out. The lines stay selected, so pressing it again undoes it.

Completion offers names as you type, or on Ctrl+Space. It lists the script's own functions, their arguments and the variables it assigns ahead of the command window's vocabulary. Enter or Tab accepts the highlighted entry.

F12 goes to where the name under the caret is defined:

• a function this script defines;
• a function another script in the folder defines (that script opens);
• for a variable, the line that first assigns it;
• on a run helpers line, the script helpers.icore itself.

Ctrl+G jumps to a line number.

Hover over a name and rest the pointer for a moment, and a card explains it:

• a function this script (or another script in the folder) defines: its signature and where it is defined;
• a command or function of the command window: its signature and what it does, as help would say.

Over an underlined problem (see Problems below) the card gives the problem's message instead. Moving off the name, typing, scrolling or leaving the editor closes the card.

Folding. A line that opens a block with a body — function, for, if, while, switch, try — has a small triangle at the right of its line number. Click it to fold the block: its body and its end are hidden and a ⋯ follows the first line. Click the triangle or the ⋯ to open it again. Ctrl+Shift+[ folds the block the caret is in and Ctrl+Shift+] opens it; View ▸ Fold All and View ▸ Unfold All do every block. Folding only hides lines: the script runs and saves exactly as written. A fold stays folded while you edit above it, below it or on its first line, and opens by itself when you go to a line inside it — Ctrl+G, a find match, a problem, a breakpoint the run stops on.

Right-click in the script for Undo, Redo, Cut, Copy, Paste, Select All, Toggle Comment, Run Selection (Run Line with nothing selected) and Go to Definition. Right-clicking outside the selection first moves the caret to where you clicked, so what the menu acts on is what you pointed at.

On macOS, every Ctrl shortcut on this page is ⌘.

Breakpoints#

Click in the margin beside a line number to set a breakpoint there, shown as a red dot; click again to clear it. A breakpoint stays with its line as you edit:

• lines added above push it down;
• pressing Enter at the start of its line carries it down with the line;
• deleting its line removes it.

Breakpoints are saved with the project. So is the line the caret was on: reopening a script brings back both. A breakpoint pauses a Debug run (below); a plain Run goes past it.

Debug ▸ Breakpoint Condition… adds two settings to the breakpoint on the caret's line:

• a condition, an expression such as k == 2, so that the run pauses there only when the condition holds;
• a hit count N, so that the run pauses from the Nth time it reaches the line.

A condition that cannot be evaluated pauses the run anyway, and the status bar says why. Both settings belong to the line, so a breakpoint that moves with an edit leaves them behind.

Debugging#

A script runs without freezing the window. You can press Stop at any time, and the script stops at its next statement. The status bar reads Running… while it runs.

Debug runs the script and pauses at each breakpoint. Run ▸ Run to Cursor runs it and pauses on the caret's line. While a run is paused:

• the line it stopped on is marked with an arrow in the margin, and its script is brought forward, even when that is another script started with run;
• Continue runs on to the next breakpoint;
• Step Over runs to the next statement at the same level;
• Step Into goes into a function the statement calls, or into a script it starts with run;
• Step Out runs until the current function or run script returns;
• Stop ends the run where it is. That is reported as Stopped, not as an error.

The Call Stack lists where the run is, innermost first. Click a row to see that level's variables in Variables and to show its line. Watches are expressions evaluated again at every pause, in the level you are looking at. Add one in the field under the list, and remove it with Remove. A watch only reads values; it never changes one.

Stop on Error pauses a run where an error happens, if no try is around it. The call stack and the variables are still there to look at. When you continue, the error stops the run as it normally would.

While a script runs or is paused, the window's own prompt, the command window and switching projects all wait. So do New, Delete and the imports.

Find and replace#

Ctrl+F (or Edit ▸ Find / Replace…) opens a bar above the script. It starts from the name under the caret when the field is empty. Every match is highlighted, and the bar counts them: 3 matches, then 1 of 3 once you step onto one.

• Enter or › goes to the next match, ‹ to the previous one; both wrap round the end of the script.
• Aa matches case, W matches whole words only, and .\* reads the query as a regular expression. In a regular expression's replacement, \1 … \9 stand for its groups.
• Replace replaces the current match and moves to the next one. Replace All replaces every match as a single edit.
• × closes the bar.

Problems#

A moment after you stop typing, the editor reads the whole script, without running it, and underlines what it finds:

• Red marks what would stop the script: a block with no end, a stray end or else, unbalanced brackets or quotes, a function defined inside another function.
• Amber marks what only might cause trouble:
  • a name nothing defines. It may still exist when the script runs: a function that only another script defines exists once that script has run.
  • a function that another script in the folder also defines. Script functions are shared by everything that runs in a session, so whichever script ran last decides which one is called.

Problems gives each one's message and line, with the last run's failure on top. Its title carries the count. Resting the pointer on an underline shows its message too.

Variables#

The Variables table shows the workspace that scripts and the command window share. For each variable it shows the name, its class, its size as whos prints it, and a one-line value. It refreshes after every run, and within a couple of seconds when the command window changes the workspace.

Files on disk#

You save a script yourself, with Save or File ▸ Save All. A tab with edits not yet on disk shows a dot, and the window's title shows a •:

• switching to another tab or script keeps the edits in their tab, unsaved;
• Run, Debug and Run All save every tab with edits first, so a run always runs what is on screen. Run Line does not save;
• closing a tab with edits, or the window, asks: Save, Discard or Cancel.

File ▸ Autosave saves silently instead, whenever you switch or close; the choice is kept per project. A save that would change nothing is skipped.

A script can also change on disk while it is open, for instance through run, Import MATLAB or another editor. The window checks the file every couple of seconds, and again before every save:

• No edits in the window: it reloads the new version, keeps the caret on its line and says so in the status bar.
• Edits in the window: it asks once which version to keep, and the default keeps yours. It asks again just before a save would overwrite the other version.
• The file was deleted: the script stays in the editor, and the next save writes it back.

New scripts in the folder appear in the list without reopening the window.

The window also remembers, per project, the scripts you had open in tabs, the one you were looking at, and the sizes of its panes. It comes back that way the next time you open it.

Keys#

Not there yet#

• Folds are not remembered between sessions.
• A script moved into or out of a secondary window keeps its text, caret line and breakpoints, but not its undo history.
• On macOS the syntax colours carry no bold or italic.