Not knowing Obj-C, the regex bit doesn't look any worse than the rest of it :). Although I can vaguely see how it's worse than a simple regex-matching function call or something.
Re:1—actually it could help, since I'm not typing numbers into QS, I'm looking up Address Book entries. If I were typing numbers, I'd just open Telephone with QS and then type there, but Telephone's address book search sucks. 2 seems to be the sticking point. A plugin makes sense, but yeah, I don't know how to write one. I'm not horribly badly in need of this feature, so I'm happy enough to wait and see. One thought—could the services menu plugin, specifically, provide its own pref panel to associate service actions with QS types? Now that I think about it _that_ would be the elegant way to do it, since services are the only common actions that QS can't get types for. Of course my lack of Obj-C knowledge leaves me stuck once again. On Jun 27, 9:37 am, Rob McBroom <[email protected]> wrote: > On Jun 26, 2011, at 3:06 PM, Daniel wrote: > > > Well, ultimately a fully general system would be nice. I don't expect > > this to be implemented any time soon, but what about: > > > 1. A new "types" tab, allowing users to define regular expressions to > > match a piece of text that give it a "type" the way email addresses, > > URLs, and calculator strings have now. > > We’ve talked about allowing plug-ins to add “string sniffing” abilities. The > user-provided regular expression idea is interesting, but regex support in > Objective-C leaves a lot to be desired. For instance: > > https://github.com/quicksilver/RemoteHosts-qsplugin/blob/master/Remot... > > Awful. > > There actually is a type for phone numbers already (QSCOntactPhoneType), but > there are two reasons why this isn’t helping you. > > 1. That type is assigned to phone numbers that are scanned in from Address > Book entries, but it will never be assigned to things you type, paste, grab > from another application, etc. > 2. Actions provided by plug-ins can target specific types, but actions that > exist as services can’t. I think the Services plug-in gives Quicksilver some > basic understanding of what data a service applies to, but the operating > system doesn’t know about Quicksilver’s type for phone numbers, so there’s no > good way to line those up. > > I guess I’m saying that I think a plug-in is the right way to solve this, but > that might not be completely fair since I know how to make plug-ins. :) A > plug-in would also solve the problem for a lot of people instead or requiring > everyone to duplicate the more common/useful associations. > > -- > Rob McBroom > <http://www.skurfer.com/>
