Add markedit-file-explorer v0.1.3

[dorkusprime]

First, thank you for MarkEdit. I love it: it's fast, native and a genuine pleasure to write in, and MarkEdit-api makes it just as nice to build on.

Why: moving between files currently means switching to Finder, ForkLift or another file manager, finding the right folder, opening the file and switching back, a small detour that breaks the focus MarkEdit is so good at keeping. File Explorer adds a VS Code-style folder tree beside the editor so that step stays in MarkEdit. In keeping with Why MarkEdit, it isn't a notes app: no index or database, just the folders you already have, as plain files.

What it does: lazy folder tree with compact folders and indent guides; click to open Markdown (other types MarkEdit can open are configurable, the rest are dimmed or hidden); inline new file / folder / rename; cut / copy / paste, drag & drop, delete to Trash; keyboard navigation; theme-matched styling. It coexists with the Outline Sidebar extension and keeps its state in sync across tabs.

• Source: https://github.com/dorkusprime/MarkEdit-FileExplorer (MIT)
• Build: a GitHub Release asset, built from the tagged commit by the repo's release workflow; CI verifies the committed dist/ matches
• Tested on MarkEdit 1.36.0 (macOS 26)

Validated with node scripts/build.mjs (including the integrity check against the release asset) and npm test.

[cyanzhong]

Thank you for your contribution. This is quite an interesting extension.

I tested it, and it seems to be mostly functional. However, I noticed that sometimes after opening a file as a new tab, the file selection switches back to the previously selected file.

This is not a blocker but worth looking into.

[cyanzhong]

Two more AI-assisted findings:

1. [P2] Replacing an ancestor folder also moves the source to Trash — upstream source
   Cut /root/foo/foo, paste into /root, and choose Replace. The extension first trashes /root/foo, including the source inside it. The subsequent move fails silently and the cut clipboard is cleared. Neither folder remains at the intended location; recovery requires restoring from Trash. Reject replacement when the destination contains the source, or implement a safe staged move.

2. [P2] An unreadable directory is reported as successfully copied — upstream source
   Folder copying converts a failed listFiles() result into [], then returns success. A permissions or access failure therefore produces an empty—or partially populated—copy without warning. Preserve the failure, report it to the user, and distinguish incomplete copies from successful ones.

Both were reproduced against the tagged TypeScript using mocked MarkEdit file APIs, not through the live macOS UI.

[dorkusprime]

Thank you for the feedback @cyanzhong! Looking into these items now.

[dorkusprime]

Hi @cyanzhong, thanks again for testing so thoroughly!

Regarding the issue you found manually - selection switching back after opening a tab - I've been clicking around like mad trying to repro, but haven't been able to catch it happening. A few questions, if you have a sec:

1. Were you single-clicking or double-clicking files in the explorer?
2. Was it MarkEdit's active tab that switched back, or the highlighted row in the explorer?
3. Which Tabbing Mode were you using, and which MarkEdit build?
4. Roughly how many files are/were in the folder, and was the explorer scrolled?

My best guess so far, explaining some of the questions: with a double-click, the new tab can appear before the second click comes in, so that click reaches the new tab's explorer and can open whichever row happens to be under the cursor when the second click registers. But I don't want to go modifying click timings or anything until I can figure out if that's what's happening.

Another possibility: Might it be interacting poorly with another installed extension?

Now regarding your two P2 findings: both confirmed, good catches! I'll fix them in 0.1.2, add regression tests for both scenarios, and update this PR to point at the new release.

[dorkusprime]

Both P2s findings are now fixed in v0.1.2, and I've updated this PR to point at the new release:

• Replace: when the existing item contains the source, Replace is no longer offered (only Keep Both or Cancel). Other replaces are now staged: the source is parked beside the destination, the old item is moved to the Trash, then the source is renamed into place, with each step undone if a later one fails.
• Copy: copies are now all or nothing. An unreadable folder or file is reported (naming the path), and any incomplete copy is removed.

Failed moves and copies are also reported now instead of skipped silently. Both of your scenarios are covered by regression tests against mocked file APIs (test/ops.test.ts).

[dorkusprime]

Discovered a couple minor UX bugs while testing - fixing and pushing a new version shortly

[dorkusprime]

pushed, all good 👍

[cyanzhong]

Thank you for the updates!

[cyanzhong]

@dorkusprime I am working on some new APIs and it may be useful for this extension:

openDocument(path: string, options?: { target?: 'automatic' | 'window' | 'tab' }): Promise<boolean>

Instead of relying on MarkEdit as the default app for markdown files, this API ensures opening plain text files in MarkEdit, and can specify the window grouping strategy.

Also:

showOpenPanel(options?: OpenPanelOptions): Promise<string[] | undefined>

This prompts the user to open a file or directory and returns the file paths.

[dorkusprime]

@cyanzhong Oh awesome, I was actually thinking about submitting a feature request along those lines to drop some of the workarounds and expectations in the extension.

showOpenPanel is a nice win too; the "Open Folder…" text box isn't the best UX and feels like a stopgap.

I'll switch over as soon as these land, and I'm happy to test a pre-release build if that helps.

Thanks again for merging!

[cyanzhong]

Feel free to test the API using this preview build:

MarkEdit.zip

I am still working on a few things before I can finalize the next release.