[TxMt] (no subject)

Allan Odgaard throw-away-1 at macromates.com
Wed Jun 21 15:59:41 UTC 2006


On 21/6/2006, at 16:59, Rob McBroom wrote:

> Now, not that I don't *love* going through this process with every  
> cutting-edge update, but could there be a preference (perhaps  
> hidden) for disabling this behavior?

Since the only “communication” I do about handling files w/o  
extensions is through supplying this information in the Info.plist,  
such “preference” would basically mean I would have to check the  
setting on each new TM release and do the exact same steps you  
outlined, just do it automatically for you -- but then, likely you  
could script all the parts except re-login, but I don’t believe that  
is necessary. Though you may have to relaunch Finder -- that can be  
done with: killall Finder, it will relaunch automatically after that.

As for editing the Info.plist, create a patch of the Info.plist  
(using diff -u) and apply it, instead of “hand editing.”

So your script should boil down to:

    patch …/Info.plist <tm_info_plist.patch
    lsregister …
    killall Finder

To automate it further, put in a LaunchAgent which monitors  
TextMate’s Info.plist and runs the script when that file has changed  
(which would happen after an update) -- actually, I am not exactly  
sure if the notify would work on the Info.plist, depends on how LA  
works. But you likely could monitor TextMate.app.

I am not suggesting this is straight-forward for the casual user, but  
as I see it, putting this inside TM as a preference is really a  
kludge to workaround how Finder currently use the LS database. I.e.  
flushing the LS database and killing Finder is not something an  
application should do, unless absolutely necessary.

> Or could it just be removed?

Before I added it, I had a question roughly every week about “how  
can I make files w/o extension open with TM” — since I added it,  
I’ve had 3 people comment on the disadvantage of the feature, yours  
included, and one was content with the new feature when I gave him a  
(nicer) solution to the problem that he had (he wanted a shell script  
to open as part of his login items, and had saved this w/o extension  
relying on Finder’s / LS’s current handling of this -- the  
workaround was to save a Terminal session instead (with the command)  
and put that in the startup items.)

So for now I won’t remove the feature -- but I am also not  
completely happy with the situation (that users basically need to  
edit Info.plists to disable it.) -- similarly though it also sucks  
that document specific icons can’t be placed in the bundles, this  
could actually put weight behind the argument that TM should take  
charge over its own Info.plist, but in addition to killing Finder and  
flushing the LS database, there is also breaking the rule that TM  
should treat ‘TextMate.app’ as read-only (which it might very well  
be for some users.)

> Personally, I use Path Finder, which allows you to right-click any  
> file and open with the [GUI] editor of your choice.

If you are using Path Finder, then there is the possibility to file a  
request with them, about their current handling of this.

AFAICT Finder has this procedure for determining a file type:

  1) does LS return an app for it? use that apps definition
  2) does the file have a scpt extension? then it’s an AppleScript
  3) is the file executable? then assign Terminal to it
  4) everything else failed: give it to TextEdit

To the best of my knowledge, the applications used for step 3 and 4  
are hardcoded.

The “problem” here is that suddenly TM is returned in step 1, not  
because TM says it can handle executable files, but because it says  
that it can handle everything, and no other app says that, nor does  
Terminal say that it can handle executable files, thus TextMate is  
chosen simply because no other app can apparently handle the file.

So the real problem here is that Terminal (or iTerm, etc.) does not  
announce to the system, that they can handle executable files. There  
is a reason though, the system does not support it.

> (It's always the first choice on the context menu, so it's not as  
> bad as it sounds.) But even if you're using Finder, you can just  
> drag unidentified files to TextMate's Dock icon, right?

Using ⌘↓ or ⌘O is for many preferred over grabbing the mouse,  
and dragging it half a meter, or holding down control, clicking the  
file, navigating to the Open With submenu, and I believe (before I  
added the entry in the Info.plist) select “Other…” and locate  
TextMate in a file dialog.

> I didn't see a request like this in the Wiki. Am I correct in  
> assuming I should add it there?

I am aware of the problem, so there is no need to file a request,  
unless the request is specific about a clean solution to the problem.




More information about the textmate mailing list