Editor support

Your editor gets the compiler's own view of your code through the language server, jadpo lsp: errors while you type, hover, go to definition, find references, completion, formatting and quick fixes. It has no parser of its own, so it never disagrees with jadpo check.

The VS Code extension

The VS Code extension starts jadpo lsp for .jadpo files, so everything the server gives works in VS Code. It formats .jadpo files on save by default. It highlights keywords, declarations, types, strings, numbers and quantities, comments, operators, route paths and use lines.

The jadpo.server.path setting names the binary: jadpo on your PATH by default, where the installers put it. A language status item names the jadpo running and its version. When none is found, or it didn't start, the item says so with the one step to take, and a notification says so once. Nothing is shown when all is well (the CLI design language).

"Jadpo: Open Generated File" lists the readable files jadpo check wrote in build/, grouped by folder, leaving out build/rust/ and build/target/. It opens the one you choose, and its refresh button runs jadpo check again. The extension's README covers installing it, its settings and its commands.

Each release packages the extension at the release's version and publishes it to the VS Code Marketplace and Open VSX once the release's installers are out.

Errors and hover

jadpo lsp gives the errors jadpo check gives while you type. It keeps one database of the project for its whole life, so an edit rechecks only what it changes.

Hovering over a name shows:

• its declaration, written as Jadpo, and its /// description;
• for anything you can call, the failures it can produce;
• for a failure, its code, kind and status;
• who calls or uses it;
• for a route, its full method and path (HTTP).

Hovering over a query, where it is declared or called, shows its generated SQL once the project has no errors: the statements jadpo sql prints from the same plan, one block for the query and one for each include (Reads and writes). The SQL is never written into your source as a comment.

Go to definition and find references

Go to definition works from every use of a name: in a body, a signature or a use line (Imports). From a translations.<domain>.<message>(...) call it goes to the message's type and to its wording in each language file (Configuration and time).

Find references lists every name in the project that the checker resolves to the same declaration, or to the same parameter or variable in its body. A private name of the same spelling in another domain is never counted.

Formatting and quick fixes

Formatting in the editor runs jadpo fmt's own code on the text the editor holds, saved or not. When every file parses it fixes the imports, then lays the file out, as one edit of the whole document. A file that doesn't parse gets no edit.

Every error whose next step carries edits is a quick fix, named after that step without the command line's "or run ..." alternative. It makes the same edits jadpo check --json gives an agent. Promotion is one of them, made as jadpo fmt --layout makes it: the move, every file's imports fixed, and each file the move touched laid out if it was laid out before. An editor that resolves code actions only gets a quick fix's edit once you choose it.

Code actions

A code action is something the editor offers on a piece of code, which you choose to apply. Each goes through the same code as a command, so the two never behave differently.

• "Make this a setting", on a constant's declaration or any read of it, works as jadpo config move <constant> does and refuses what it refuses. A move it can't make is offered as unavailable, with its reasons. Its edit replaces each changed file, creates config.jadpo when there is none, and deletes a file the move empties. It is offered, not a fix for an error, so jadpo fmt --layout, which makes only the moves errors ask for, never makes it (Making a constant a setting).
• "Decline with a reason", a quick fix on a finding you can decline, writes decline <rule>: "" above the declaration the finding is on. decline.no_reason asks for the reason until you write it. "Remove decline", on a decline line, removes the line. Both work as jadpo declines clear does (Declining a judgement call).
• "Swap for the standard ...", a quick fix on type.standard_clash and type.standard_exists, works as jadpo fix <name> swap does. Where the command stops, it is unavailable and shows the error it would add. Renaming instead needs a new name, so that stays with the command until the editor's rename comes with jadpo rename (A release that adds a standard type).

Completion

The editor offers completion for everything as you type. It is generated from the same declarations and data the compiler uses, never from a list kept for the editor: the project's name and type tables, the standard library's stubs and the standard types' data entries, the operation, unit and enum tables, the rule catalogue, the settings, the translations' messages and the parser's own keyword sets. So every type, unit and operation added to Jadpo is offered with no editor code of its own.

Where the position needs a value of a known type (an argument, a field, a variable's declared type, a return), what fits comes first, and a unit or a variant that can't go there isn't offered. What it offers:

• Names in scope in a body: locals and parameters, the file's constants and its domain's callables, types, libraries, the domains it may call into and the standard namespaces. A project name the file doesn't import yet comes with its use line, the edit jadpo fmt would make. Another domain's private name isn't offered.
• Members after a value: note. offers the fields the checker reads from its type.
• Operations after a namespace: list., text., temporal. and the rest offer each operation with its signature, the failures it can raise and its description, from its stub.
• Variants after a type: Shade. offers the enum's variants. A standard type's are shown with the name its data entry gives people (Locale.en_gb is "British English").
• Units straight after a number, narrowed to the type it goes into: after 2 where a Duration is required, d, h, m, s and ms; none where an Int is. The units come from the standard library's own table, so quantity types offer theirs once they have units.
• Named arguments of the standard-library call being written, those not given yet, the required ones first; and the fields not given yet of a record being built.
• Type names, the application's and the standard ones, wherever a type is written.
• Rule ids after decline: only the rules you can decline.
• config.: the settings. translations.<domain>.: the messages.
• Keywords where a declaration or a statement may start.

Choosing a call with required arguments inserts it as a snippet, with a placeholder for each argument. For a standard-library operation the first is in its place and the rest are named (temporal.resolve(${1:date}, at: ${2:at}, zone: ${3:zone})). For the application's own callables every one is in its place.

The server offers what the compiler knows and nothing else: suggestions written by a model belong to your agent, never to jadpo lsp. VS Code asks for completion as you type a word, a ., a : or a digit.

Not built yet: publishing the extension, which is switched off until the Marketplace and Open VSX are set up; and rename in the editor. It goes through the same code as jadpo rename, so an entity field renamed in the editor keeps its stored data, and it waits for that command and the identity registry it writes (Data, Stable identity).