feat: accept a .torrent dragged onto the search field - #147
Open
ugurckr wants to merge 1 commit into
Open
Conversation
Dropping a file on a terminal pastes its path into whatever is reading input, which is already how people expect to hand a client a .torrent. The search field took a magnet or an infohash but treated a path as a search query, so the obvious gesture silently searched for "C:\Users\..." instead. Each emulator escapes that path its own way and none of them agree: Windows Terminal and PowerShell wrap it in double quotes and leave a trailing space, macOS Terminal and iTerm2 escape spaces and parens with backslashes, GNOME Terminal pastes a percent-escaped file:// URI. resolveTorrentPath unwraps all three back to a plain path, with the backslash rule split by platform -- an escape on macOS and Linux, a path separator on Windows, so a Windows path is never mangled. Its tests drive both platforms from either host rather than only the half that matches the runner. Paste (v) takes a path too, since copying a file in a file manager puts one on the clipboard, and `torlnk <file>.torrent` runs its argument through the same normalizer so a shell-quoted or file:// argument works there as well. A path that turns out not to be a readable torrent says so rather than falling back to a search, so the failure is never silent. No new key, no change to an existing one -- Enter on the search field already meant "do something with this", and this widens what it accepts. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What and why
Dragging a file onto a terminal window pastes its path into whatever is reading input. That's the
gesture people already reach for when they have a
.torrenton disk, and torlink half-supportedit: the search field took a magnet or a bare infohash, but a path was just a search query, so the
obvious move silently searched for
C:\Users\...\thing.torrentand found nothing.torlnk <file>.torrentworked from the shell, but there was no way in from inside the running app.The search field now recognises a
.torrentpath and downloads it. The work is in getting thepath back out of what the terminal actually pastes, because no two emulators agree:
"C:\Users\u\My Show.torrent"plus a trailing space/Users/u/My\ Show\ \(2024\).torrentfile:///home/u/My%20Show.torrentresolveTorrentPathunwraps all three. The backslash rule is split by platform — an escape onmacOS and Linux, a path separator on Windows — because unescaping a Windows path would destroy it.
It takes the platform as an option rather than reading
process.platformonly, so the tests driveboth from either host instead of covering only the half that matches the runner.
Two smaller things follow from the same helper: paste (
v) takes a path too, since copying a filein a file manager is how a path gets on the clipboard in the first place; and
torlnk <file>.torrentruns its argument through the same normalizer, so a shell-quoted orfile://argument works there as well.
A path that turns out not to be a readable torrent reports that, rather than falling back to a
search — the one thing worse than not supporting the gesture is supporting it silently badly.
No new key and no change to an existing one.
↵on the search field already meant "do somethingwith this"; this widens what it accepts, next to the magnet and infohash cases that were already
there. The splash placeholder now says so.
Checklist
npm run typecheckis cleannpm testpasses — with one caveat: on my Windows box 5 test files (daemon/runtime,daemon/serve,daemon/watch,download/queue,download/queue.safemode) fail to loadnode-datachannel. They fail identically on a cleanmainhere, so it's my environment andnot this change. Everything else passes, including the 15 new tests.
src/sources/torrentPath.test.ts, covering all three emulatorshapes on both platforms,
~expansion, uppercase extensions, and the cases that must staya search (plain query, magnet, blank, a non-torrent file).
HELP_GROUPS/footerHintsare unchangedStorefield, somakeStoreis unchangedNote on ordering
This is independent of my other PR (
fix: keep a torrent's own trackers…) and the two touchdifferent files, so they merge in either order. They do compose, though: dropping a private
torrent's file is exactly the case where the discarded announce list mattered most.