-
Notifications
You must be signed in to change notification settings - Fork 13
Improve magnet link handling #14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
|
It might be wiser to merely alter the input mechanism. But I have to admit, the goals of interactive |
|
Providing a recipe would be helpful: at the very least an actual magnet link that causes the issue. The only problem I have is with with magnets that aren't hexified, so the slashes are treated as paths. Also see #2. Alternatively, in older Emacsen, the pasted '?' is treated as an attempt at completion, which is troublesome. As for the design, an abnormal hook is run, the first result--if any--from any function in the hook is used as the default in the prompt. Every result from the abnormal hook is made available to the prompt, so you can cycle through them with M-p and M-n. |
An example of offending link (no explicit slashes): Note: I normally use ido (ido-mode is always on). However, |
assimilated from a bug fix in elisp-json-rpc
it was added in emacs commit 85b3d352c for bug#16567, and so was not in a release until emacs 25. cl-ecase is ok, though not fond of its use of eql
* transmission-remote source moved * marmalade is dead
|
What is the current way you're supposed to add magnets? Calling the LISP function? I've discovered that all TUI interfaces to transmission suck, and this seems pretty decent and has a set of intuitive shortcuts, but giving that basically all mayor torrenting is done with magnets not having decent magnet link support makes this a pain to use. |
…smission into improve-magnet-link-handling
Interactive
transmission-addis quite broken for magnet links at the moment.Arguably, magnet links are almost always provided via kill ring, or are fed into transmission-add non-interactively. Non-interactive use shows no issues. (When I
(transmission-add "magnet:?xt=...")from repl, torrent is added properly.)However, when called interactively, the user is prompted: “Add torrent [...]: ”. Suppose user now removes whatever is written in input field and inserts magnet link from kill ring.
Debugger shows
transmission-add("/path/to/some/dir/magnet:?xt=..." nil)
with some directory (default-directory?) prefixed for no reason.
In addition, the prompt itself depends on a variety of sources including the last killed item in kill ring, for reasons not entirely clear to me but likely not very well thought through. When a magnet link is last killed, it is shown in the prompt while the input field contains a directory path which is extremely confusing. (Is transmission going to start this magnet download into this directory? — Alas, it is not.) Furthermore, on my Emacs (26.0.90), if 'not' is last killed, a 'notes.org' is added to the prompt, which is some extremely far-fetching guess that certainly has nothing to do with anything transmission.
I propose a patch that attempts to guess if magnet-link is provided via one of the
transmission-torrent-functions(in fact it might be better to search by means of one hook only, this is debatable). If something resembling magnet link is found, it is (attempted to be) added automatically. The prompt is not modified in this case. The latter might seem silly, as the effect is instantaneous but 1) it just doesn't feel right; 2) modifying prompt only makes sense for filenames whiletransmission-add's docstring claims to accept much more than filenames or magnet links, so it's likely that more has to yet be done in this regard.The patch does not fix misguided guessing (see the not / notes.org example above) but does not make it worse either.