Alas, none off the top of my head. You could make a shortcut for “Add Link…” then do what you’re doing but instead of right clicking when you select the hyperlink, copy it, pull up the “Add Link” dialogue and paste it there, and then hit “okay.” Doing it all with the keyboard will make it faster. If you have any addresses that start https instead of http, you’ll have to make sure that you switch from the default “web” to “no prefix” or they won’t come out right; regular http:// prefixes won’t get doubled even if you leave it on “web”, so you’re fine there.
OPML is a plain text format, and so does not store information as links. Scrivener does not try to parse imported plain text files for links or any other possible formatting - trying to determine what might be intended as a link is more tricky than it may at first sound (especially when you consider custom links that are not generally well-known, such as sente://….).
Keith - That doesn’t make sense to me since the text entry system does parse them fine when I type them into Scrivener. I’m not a software developer (anymore) so can’t easily understand why the import can’t use the same logic… Oh well.
The parsing code is handled by internal Apple code and I’m no expert. Parsing every file on import is a different matter - not impossible, but non-trivial, and not on the roadmap at the moment, sorry. I don’t rule it out for the future though. (You’ll notice that likewise, if you create a plain text file in TextEdit and type a link, it will get detected, but when you save and re-open the file, it will not parse the link and it will be plain text.)
Here’s an idea for that future implementation as to how to identify what are hyperlinks on an import:
Caveat: I am not a Cocoa or OS X programmer, except for a little Applescript so I likely don’t know what I’m talking about!
The URIs that are in use by OS X for any given user are stored in com.apple.LaunchServices.plist – Perhaps those URI strings could be loaded into a list that could be searched for (followed by the standard :// suffix), using regex perhaps, to form links. So any LaunchServices identified URIs followed by :// along with all subsequent non-blank text would be encompassed in the link? Just a thought, as I really know nothing about Cocoa and OS X programming except for a little AppleScript.
Here’s what the plist file looks like for one type:
OK, looking into this a little more, it appears the // is only for those schemes that include a naming authority. Since hyperlinks that are directed not at authorities but at resources do not include the // the format would be to look for text matching the LSHandlerURLScheme followed by : followed by the path so in the case of Sente URIs you’d be looking for something like sente:/my+library…
It appears that a slash is not required to begin the path component, so something like quicktime: might be a valid URI that would launch quicktime but not direct it at a particular movie? If you create a link in TextEdit as quicktime: it does launch Quicktime. Thus any text where there was a handler scheme followed by the colon character would infer a link, so typing “These are the features of Quicktime: (a)…” would create a link for the Quicktime: text, which would likely be undesirable.
Nevertheless, I think it’s unlikely someone would type a colon followed by characters other than a space in the normal use of English, so I think it might be safe to infer “quicktime:followedbyanytext” would be a link whereas “quicktime: followedbyanytext” would not.
The standard Mac OS text processing engine only recognizes :// as an indicator of a link, which is itself insufficient.