Tish — VS Code / Cursor extensionSyntax highlighting, snippets, a bundled tish-lsp language server, and build tasks for the Tish language. Features
End usersNo highlighting, no squiggles, no hover (extension seems dead)
Go to definition / hover (like TypeScript)These come from tish-lsp, not from TextMate grammar. After opening a
Lint vs format: Red/yellow squiggles are diagnostics (parse +
|
| Setting | Description |
|---|---|
tish.languageServerPath |
Path to a tish-lsp that overrides the bundled one |
tish.trace.server |
LSP trace |
tish.format.enable |
Format on save |
Documentation
Tasks (workspace)
Add to .vscode/tasks.json:
{
"version": "2.0.0",
"tasks": [
{
"label": "tish: run current file",
"type": "shell",
"command": "tish",
"args": ["run", "${file}"],
"group": "test",
"problemMatcher": []
},
{
"label": "tish: build (native)",
"type": "shell",
"command": "tish",
"args": ["build", "${file}", "--output", "${workspaceFolder}/tish_out", "--target", "native"],
"group": "build",
"problemMatcher": ["$tish-rustc"]
}
]
}
Development
npm install
npm run compile
Press F5 for Extension Development Host. For LSP during dev, either allow download or set tish.languageServerPath in settings.
If you previously set files.associations to language tish-jsx, change it to tish (the tish-jsx language id has been removed).
Debugging F5: prove the LSP is loading
You always have two windows: (1) the tish-vscode window where you pressed F5 (the debugger), and (2) the [Extension Development Host] window that opens (this is the “fake” Cursor/VS Code running your local extension).
Do the checks below in the Extension Development Host window, not in the debugger window.
- Launch config — Prefer Run Extension (rebuild local tish-lsp) so
../tish/target/debug/tish-lspis built and picked up automatically (requires a sibling checkout of the compiler repo next totish-vscode). Otherwise use Run Extension and settish.languageServerPathin the Host’s settings to your binary. - Open a real folder in the Host — File → Open Folder… and choose the
tishcompiler repo (or any project that contains*.tish). Until a folder is open, you may not see much LSP traffic. - Output channels — The extension uses two logs (both under View → Output):
- “Tish Extension” — always has a short boot banner; enable
tish.debug.extension(or Tish: Toggle Extension Debug Logging) for[tish-ext …]resolver / client-start detail. - “Tish Language Server” — download /
Using language server: …,tish-lsp started, LSP failures, andtish.trace.serverJSON-RPC.
If “Tish Extension” never showsTish extension activated, the extension did not activate (wrong window, or extension failed to load). Iftish-lsp startednever appears on the language-server channel, scroll for errors or see the warning toast.
- “Tish Extension” — always has a short boot banner; enable
- Command Palette — In the Host: Tish: Show Extension Output or Tish: Show Language Server Output (forces activation and focuses the matching log).
- LSP wire trace — In the Host open Settings (JSON) and set
"tish.trace.server": "verbose", then Reload Window in the Host. The same “Tish Language Server” output will log JSON-RPC (initialize,textDocument/didOpen,textDocument/publishDiagnostics, etc.). Set back to"off"when finished. - Breakpoints (extension TypeScript) — In the debugger (tish-vscode) window, open
src/extension.ts/src/downloadLsp.tsand set breakpoints on the lines afterresolveLanguageServerExecutableand aroundclient.start(). They hit when the Host activates the extension (e.g. when you open a.tishfile or run the command from step 4). - Running extensions — In the Host: Developer: Show Running Extensions and confirm Tish is listed and not disabled.
- Sanity test — In the Host, open a
.tishfile, confirm the status bar language is Tish, introduce a parse error or unknown identifier and confirm squiggles / hover.
Debugging the Rust tish-lsp binary itself is separate: build with debug symbols from ../tish, then attach a native debugger to the spawned tish-lsp process, or run tish-lsp under lldb/gdb from a terminal and point tish.languageServerPath at that binary while testing from the Host.
CI / publishing
Same pattern as tish: CI workflow plus separate release workflows per registry.
| Workflow | Trigger | Purpose |
|---|---|---|
vscode-ci.yml |
push/PR to main, workflow_dispatch | Build VSIX, release_check (conventional commits), create prerelease with tish.vsix. Mirrors build-npm-binaries.yml. |
vscode-release.yml |
release published/edited | When prerelease promoted to full: download VSIX from release, publish to Visual Studio Marketplace. Mirrors npm-release.yml. |
open-vsx-release.yml |
release published/edited | Same trigger: download VSIX, publish to Open VSX (VSCodium, etc.). |
VSCE_PAT— Visual Studio Marketplace (vscode-release).VSX_TOKEN— Open VSX (create token; sign publisher agreement first).- Conventional commits — feat/fix/perf/BREAKING CHANGE required for main merge.
- Bump the
@tishlang/tish-lspdevDependency to ship a newer language server; each platform.vsixbundles that version’stish-lsp.