Detent Point
-
01
Read →Getting startedFrom install to your first script: what you see on first launch, how sessions and script tabs work, and where your settings live.
-
02
Read →Keyboard shortcutsEvery shortcut, taken from the app’s own key bindings. The ones that match Windows PowerShell ISE are marked, because that muscle memory should transfer.
-
03
Read →How-tosStep-by-step walkthroughs of five everyday tasks: generating Pester tests, Quick Fix, targeting Windows PowerShell 5.1, F1 help, and remote session tabs.
Licensing, telemetry, and system-requirement questions live on the FAQ.
These docs cover today’s app, and they grow with it. Every step and shortcut is written against the app’s actual code, not from a roadmap or from memory of how similar tools behave. Where a page needs a screenshot, you’ll find a labeled slot instead of a mock-up; real images get captured from the launch build.
When the app changes, the docs change with it, and the changelog records what actually landed. If a page and the app ever disagree, the app is right and the page has a bug. Tell us at hello@detentpoint.com.
You don’t need this section to use the app. But if you’re evaluating DetentShell for a team, this is how the engine actually works. Each point below traces to a specific class in the app’s source.
One session per tab
Each script tab gets its own dedicated PowerShell 7 runspace. We deliberately avoided a shared pool: a pool hands out anonymous runspaces, which breaks stateful-session behavior. Sessions open asynchronously, so a new tab never blocks the UI, and a configurable cap bounds how many run at once. A session that breaks is detected, cleaned up, and reported to its tab in plain English.
Console and editor share the session
A command typed at the console runs in the same runspace your F5 runs use. Variables, imported modules, defined functions, and working-directory changes are visible both ways. That’s the workflow the ISE’s users built muscle memory on.
IntelliSense sees live state
Completion runs in-process against the tab’s own runspace, so it knows the variables you just set and the modules you just imported. While a script is running, completion quietly yields for that keystroke instead of fighting the busy session; it won’t throw or corrupt the run.
Debug runs use the same pipeline
A debug run arms the debugger on the same runspace and goes through the same execution pipeline as a normal run: same output channels, same stop behavior. The per-run timeout is stripped for debug runs, so a session paused at a breakpoint won’t be torn down for taking too long.
Test runs stay isolated
Pester tests run in a short-lived runspace of their own, never in your editor tab’s session, so a test run cannot pollute your variables. The runner uses Pester v5’s configuration API (no console-text parsing). A machine without Pester v5 gets a readable “install it with…” result instead of a crash.
Panels don’t leak
Tabs and panels talk through a thread-safe, weak-referencing event aggregator. A closed tab’s subscriptions become collectable without manual unsubscription, and dead entries are pruned automatically, so long sessions don’t accumulate ghost handlers.
A note on how this section was made: we seeded it by running WikiMint (our own documentation engine) over six core engine source files, then hand-curated the output into what you just read. The raw generated reference pages stay internal for now; they read like an API reference, which isn’t what you come to user docs for. What made it onto this page was rewritten by hand and checked back against those same files, not left as the generated draft.
PS> Start-Process "https://detentpoint.com/detentshell/download"
# Coming soon — ships once the installer is code-signedComing soon. DetentShell launches at $29.99 in the Microsoft Store for its first two weeks. The regular price that follows is not final yet and will be published here first; volume licensing for teams is handled separately.