Open Radar

 
21-Sep-2009 12:10 PM Nathan Gray:
I have written a Quick Look plugin called QLColorCode that displays source code files with syntax highlighting.  Xcode 3.2 (the version shipped with Snow Leopard) also includes a Quick Look plugin that highlights source code. It only highlights a few languages, though, so many people probably still want to use QLColorCode. However, the Quick Look server always picks the Xcode plugin over QLCC. This means that for any source code file aside from .c, .m, and the other languages that Xcode understands users will see a plain text preview with no highlighting, even if they've installed QLColorCode. 

To get QLCC to work properly users need to disable the Xcode plugin.  Nobody wants to mess around inside an .app bundle that Apple provides, or do so again after every update of said .app bundle.  This is a mess.

Quick Look needs a preferences system.  The user needs some way to tell QL that their preferred handler for the public.source-code UTI is plugin X instead of plugin Y without the need to uninstall plugin Y, which may live in a system location the user has no access to.  I can't tell you how many times users have asked me to diagnose situations where QL was picking the wrong plugin.  And I can't tell you how frustrating it is to have to tell those users, "sorry, there's nothing you can do."  Quick Look is supposed to be a service to the user, not a source of confusion.

It doesn't have to be pretty.  Something like this would be just fine:

qlmanage --bind public.source-code org.n8gray.qlcolorcode

But it does need to exist.

At the *very* least, quicklookd should consider plugins in ~/Library/QuickLook to override any others so that users can override application or system-supplied handlers.