Architecture

The plugin is an adapter, not another language implementation.

Thonny editor
   │ didOpen / didChange / LSP requests
   ▼
Thonny adapter + small JSON-RPC client
   │ stdio
   ▼
pseudo-lsp
   ▼
pseudocode-i18n

Thonny 5 integration details

Thonny 5 stable does not expose a generic configuration for launching arbitrary external language servers. The plugin therefore provides the smallest missing layer itself:

1. a JSON-RPC/LSP stdio transport;
2. document synchronization for .pseudo and .algo editors;
3. adapters to Thonny's existing completion, calltip and go-to-definition components;
4. diagnostic underlining and a command that lists current diagnostics;
5. commands for formatting, hover and rename;
6. a five-view companion UI for Diagnostics, Exécution pas à pas, Documentation, Algorigramme and Informations;
7. thin renderers for pseudocode/tutor and pseudocode/flowchart responses.

This layer contains no parser, type system, language detector, diagnostics engine, snippet catalogue, execution tracer or flowchart semantics. Those remain in pseudocode-i18n and pseudo-lsp.

Thonny's editor classes are intentionally extensible by plugins, so this project keeps the patches narrow and delegates unchanged for non-Pseudocode documents.

Position encoding

Tk text columns are Unicode code-point offsets. The client therefore offers utf-32 during LSP initialization. pseudo-lsp negotiates that encoding, which prevents column mismatches for non-BMP Unicode characters.

Future Thonny versions

The development branch for the next major Thonny version contains a generic language-server proxy API. Once such an API is part of a stable Thonny release, this project's transport can be replaced by the native proxy while keeping the same pseudo-lsp server and Pseudocode core.

Tutor / flowchart protocol boundary

The active .pseudo / .algo document is synchronized through normal LSP lifecycle messages. Tutor and flowchart requests carry that document URI explicitly. The language server normalizes accepted URI representations through one common parser and delegates to pseudocode-i18n. Thonny only renders the returned editor-neutral structures, which is the same architecture used by VS Code and intended for future Kate, Neovim, Spyder and Pyzo adapters.

The synchronized Tutor algorigram uses the same Mermaid source and layout engine as VS Code. embedded Mermaid rendering is asynchronous, cached and coalesced, and happens only when the graph scope, Thonny theme or settled pane width changes. The single Mermaid SVG is parsed once in O(V+E) and its exact geometry is drawn directly on the Tk Canvas for both normal and active strokes, eliminating PNG/SVG coordinate drift. Tutor stepping never invokes Mermaid: it only hides/shows the node and edge items whose active state changed, so the per-step flowchart work is O(Δ), where Δ is the number of changed active items.