Linelark Notepad Studio
What shipped in 1.16.0.
Closing the last tab leaves the window standing
- Safari’s rule was here first, and it threw away the thing you are most likely to want next. The page that replaces the last tab is the list of files and projects to carry on with — and a window that vanishes takes that list with it, along with the folder tree, the shells and the agent it was holding.
- ⌘W again, with nothing left to close but the window, closes it. The gesture still ends in the same place; it is two presses now, and the second is the one that cannot be undone. Close All has always emptied a window and left it standing, and a tab’s own ✕ cannot take a window with it however few tabs are left.
- ⇧⌘N opens on that same page, which is the other half of the thought: a new window is not made with a file already in mind, it is made when there is somewhere else to go, and the page is the list of where. A window opened for something — a project double-clicked in the Finder — shows no page at all, because the question it asks has just been answered.
The welcome page says what makes this a development environment
- Git, a build, something to run, a rendered document and a side-by-side diff are what somebody arriving from VS Code or Xcode expects an editor to already have. In Linelark each of them is a plugin — a deliberate split, since the editor stays small and what a particular kind of work needs is installed — but it only works if the person who needs them is told they exist. On a first launch both recent lists are empty, so what was on screen was four buttons and a link.
- Under the recent files and projects there is now a short, named list: GitHub, Build and Run, Launcher, Document Preview and Compare Files, each with a line about what it adds, and a sentence saying plainly that these are recommendations for that one purpose and that none of them is required. Five rather than the catalog, because a recommendation that lists everything is not one — the rest is a click away in Browse all plugins…
- Clicking a name installs it, through the reviewed catalog and nothing else: same checksum, same permission prompts, same questions Get Plugins… asks. The catalog is fetched at the moment you click rather than when the page is drawn — the list itself is compiled into the app precisely so that opening a window asks the network for nothing.
- Installed ones drop out, and the section goes with the last of them. A page that goes on recommending what is already there is a page you learn to skip.
- The Mac App Store edition offers only the two that work in it. The sandbox has no terminal, no git and no network for plugins, so the other three would install perfectly there and then draw a panel that does nothing — which reads as a broken plugin rather than as an edition that cannot carry it. That edition may not fetch code at all, so a click there opens the plugin page on linelark.com, where the download and Plugins ▸ Install Plugin… are the way in.
A project double-clicked in the Finder gets a window of its own
- Opening a folder or a
.code-workspaceover the front window was the one Finder gesture that could take work away without asking. The tabs survived, but the folder tree, the search scope, the shells and the agent all belonged to the project that was there — and the window you double-clicked from is by definition not the one you were looking at. - A window holding nothing — no project, and nothing typed into it — is filled rather than left behind for you to close afterwards. Files are unchanged and still join the window last used, which is what a second
openon VS Code does.
⌘⌫ moves the selected row to the Trash
- The Finder’s gesture on the Finder’s key, through the confirmation the folder tree’s Delete… item already put up.
- The whole difficulty is that ⌘⌫ already means delete to the beginning of the line inside every text view on this platform, and a menu item’s key equivalent beats whatever is typing. So File ▸ Move to Trash is enabled only while the folder tree holds the keyboard — a disabled item does not take the key at all, and the keystroke goes where it always went.
Get Plugins… says when a plugin runs commands
- The one line under each plugin was computed from git and network access alone, so Build and Run — which asks to type
xcodebuildinto a shell and to run a command out of sight and read what it printed — was described to the person about to install it as “No network or git write”. Three true words that together said the opposite of the truth, on the one screen where that decision is made. The Launcher had been described the same way since it shipped. - Running commands is named first now, because it is strictly heavier than either of the others: anything git write or a host grants, a command can do anyway. Nothing had to be resubmitted — the capabilities come from the manifest stored with each release, so regenerating the feed describes the old ones correctly and leaves their archives and checksums untouched.
Known limits in 1.16.0
- The recommended list is compiled into the app, which is what keeps the welcome page from asking the network for anything until you click. A plugin published after a release is not named there until the next one — the catalog always has everything.
- Installing from the page is Studio’s. The Mac App Store edition fetches no code at all, so a click there opens the plugin page on the site and the install is the one it has always been: download, then Plugins ▸ Install Plugin…
- ⌘W on the last tab of the only window still quits Linelark, on the second press — there is nothing else for a window to go to.
- There is still no watchdog over a plugin’s own script: one that never returns hangs the app, because the only way to interrupt it is private API that cannot ship on the App Store.
- Code folding and recorded macros remain roadmap items with no promised date.