Linelark Notepad Studio
What shipped in 1.11.0.
A plugin can run commands — in a terminal you can watch
- A plugin that declares
"terminal": "run"and is granted it can hand command lines to a shell in the terminal panel, which is then shown. It does not get a process of its own: the commands are typed at a shell, exactly as you would type them. - Nothing comes back to the plugin — no exit status, no output, no promise — and that is the design rather than a gap in it. Anything given a hidden process would need somewhere to put its output, a way to be stopped, and a way to answer a password prompt. The panel is already all three: the output scrolls where you can read it, ⌃C stops it, and ↑ runs it again long after the plugin’s panel is closed.
- It takes a click. A timer cannot start anything, nor can a panel drawing itself, nor anything after an
await— which ends the gesture the host checks for. A plugin that runs commands while nobody is at the machine is the thing this rule exists to prevent. - Its own switch in Manage Plugins, kept apart from network and git because it contains both: a command can do anything you can do. Granting either of the others never grants this, and revoking it stops the next command rather than the next launch.
Launcher, in the plugin catalog
- The applications a project is made of — a server, a worker, a watcher, a test run — each with its folder and the two or three lines that start it, one click away and each in its own shell. Running the same one twice goes back to the pane it used rather than opening another.
- It is also the worked example for a panel that saves as you type: there is no Save button, because a form that gathers what is typed and commits it on a click loses the last half-second before that click.
A folder picker that asks for nothing
chooseFolderputs an open panel on screen and hands back the one folder somebody picked. It needs no declaration and no switch, for the reasonexportFilenever needed one: the panel is the permission. A plugin still cannot name a directory and be given it.
One thing that was slow
- The session snapshot rewrote every unsaved buffer whenever any one of them was typed in — each rewrite bridging a whole storage string on the main thread — so a window holding a few large dirty buffers paid for all of them a couple of seconds after every burst of typing. It now writes only the buffers whose text actually moved.
Known limits in 1.11.0
- A plugin is never told what happened to what it ran. There is no exit status and no output, so a panel can say a command was started and nothing more; what happened is in the terminal.
- Running commands is Studio only — the sandboxed Mac App Store edition has no terminal panel at all. A plugin cannot tell that apart from a permission nobody has granted yet, since
canRunInTerminal()is one boolean, so a good one names both. - A second run types into the same shell. If what you started last time is still running — a server, a watcher — the new lines go to that program’s input, exactly as they would if you typed them at it.
- Commands are typed as one line joined with
;, so each runs whether or not the one before it worked. Ask for the other thing by writing&&yourself. - Code folding and recorded macros remain roadmap items with no promised date.
