Skip to content

Commit 07c15a2

Browse files
Merge pull request #90 from pyscript/issue-82
Fix #82 - Expand on Editor vs Terminal
2 parents 3d31c58 + c8d1f52 commit 07c15a2

File tree

1 file changed

+19
-0
lines changed

1 file changed

+19
-0
lines changed

Diff for: docs/user-guide/editor.md

+19
Original file line numberDiff line numberDiff line change
@@ -96,3 +96,22 @@ editor will be rendered:
9696
</script>
9797
<div id="editor"></div> <!-- will eventually contain the Python editor -->
9898
```
99+
100+
## Editor VS Terminal
101+
102+
The main difference between these two core plugins is that a *py-editor*, or *mpy-editor*, is a custom orchestration a part and editors run in workers by default, mostly to prevent accidental blocking evaluation that could otherwise freeze the main thread UI (infinite loops or similar deadlocks).
103+
104+
Because an editor is detached from the regular orchestration that happens with just *py* or *mpy* scripts, one should not expect the same behavior regular *PyScript* elements follow, most notably:
105+
106+
* the whole editor is based on [CodeMirror](https://codemirror.net/) and not on *XTerm.js* as it is for the *terminal*
107+
* the code is evaluated all at once and *always async* when the *Run* button is pressed, not per each line
108+
* the editor has listeners for `Ctrl-Enter`, or `Cmd-Enter`, plus `Shift-Enter` to shortcut the execution of the code. These shortcuts make no sense in the *terminal* as each line matters
109+
* there is a clear separation of the input and the resulting output
110+
* simple to complex programs can be written without executing
111+
* there is no special reference to the underlying editor instance, while there is both `script.terminal` or `__terminal__` in the *terminal* case
112+
113+
## Still missing
114+
115+
As mentioned at the top of this section, the *PyEditor* is currently under further development and refinement, and it might land also as explicit custom element such as `<py-editor>` or `<mpy-editor>`, somehow simplifying the bootstrap through its content-aware element nature but right now these variants are *not* supported.
116+
117+
Last, but not least, we currently don't have a mechanism to destroy a terminal or kill its execution from the worker so in case of infinite loops, the easy way out is to refresh the current page so that previous worker would get killed. We will eventually provide an easier way to kill and start fresh in the future.

0 commit comments

Comments
 (0)