As of rev 948:
[NEW] Files without extension now open in TextMate (instead of TextEdit) when double-clicked in Finder.
True, this is probably what most of us want in theory, but implementing it this way has undesirable side-effects. For example, all of your shell scripts are identified as "Document" instead of "Unix Executable File" and their icon becomes the default blank page thing.
Anyway, the reason I'm writing is to share steps for getting things back to normal, in case others are bothered by this as well.
1) Locate TextMate.app and "Show Package Contents" or "cd" into it or whatever 2) Go into the Contents folder 3) Open Info.plist in your favorite text editor. ;) [I've done this with TextMate itself and had no problems.] 4) In the array of <dict> tags for document types, find the one that has "****" under CFBundleTypeOSTypes and comment it out (or delete it). In the latest version of TextMate (1112), this item is the last document type and can be found on lines 781-796. 5) Save the file 6) Run this command (all on one line): /System/Library/Frameworks/ ApplicationServices.framework/Frameworks/LaunchServices.framework/ Support/lsregister -kill -r -domain local -domain system -domain user (Looks like the kind of thing you would run using "sudo", but don't because it won't get your "user" domain.) 7) Stop everything you're doing, make sure everything is saved, and hope you remember everything you were working on 8) Log out 9) Log in
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? Or could it just be removed? Personally, I use Path Finder, which allows you to right-click any file and open with the [GUI] editor of your choice. (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? I didn't see a request like this in the Wiki. Am I correct in assuming I should add it there? Thanks.
Rob
Sorry about the "no subject". Forgot to go back and add it. Hopefully, this reply will at least make it somewhat easier to locate in the archives.
Rob
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.
On Jun 21, 2006, at 11:59 AM, Allan Odgaard wrote:
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.
Good idea. I'll most likely do this for now.
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
Fair enough. I was aware of the difficulties you described with making it a preference, but I thought suggesting outright removal alone would be too presumptuous. :) Based on what a minority I seem to be in, it looks like I was right.
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.
Well, I mentioned it because I like the feature, so I wouldn't really have anything to ask them for. I suppose a keyboard shortcut for this menu option would make it even nicer, like ⌘E to "edit". I tried to add it in System Preferences, but it isn't working. My guess is that because you can specify an editor in Path Finder's prefs, the name of the menu could change, so while the menu item might look look like "Open with TextMate" to me, to the system, it probably looks like "Open with $EDITOR_THE_USER_CHOSE" or something.
AFAICT Finder has this procedure for determining a file type:
- does LS return an app for it? use that apps definition
- does the file have a scpt extension? then it’s an AppleScript
- is the file executable? then assign Terminal to it
- 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,
Yes, I suppose a proper fix would depend on Apple.
but because it says that it can handle everything, and no other app says that,
I can't help thinking that this was no accident (i.e. no app is *supposed* to say it handles everything), but I'll shut up about it now.
nor does Terminal say that it can handle executable files, thus TextMate is chosen simply because no other app can apparently handle the file.
I would actually like such files to open in TextMate when double- clicked, rather than be executed (which I imagine Terminal would do). If I want to execute one I'll do it from the command line. It's just that I would also like them to be correctly identified by the Finder, etc.
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.
OK, I'll forget about the feature request aspect, but maybe a Howto on manually disabling would be useful?
Rob
On 21/6/2006, at 20:20, Rob McBroom wrote:
If you are using Path Finder, then there is the possibility to file a request with them, about their current handling of this.
Well, I mentioned it because I like the feature, so I wouldn't really have anything to ask them for.
I was thinking of asking them to explicitly detect shell scripts, which seems to be the essence of your disliking: that having TM associated with unknown files no longer show them as shell scripts, even when they are.
I suppose a keyboard shortcut for this menu option would make it even nicer, like ⌘E to "edit". I tried to add it in System Preferences, but it isn't working. My guess is that because you can specify an editor in Path Finder's prefs, the name of the menu could change, so while the menu item might look look like "Open with TextMate" to me, to the system, it probably looks like "Open with $EDITOR_THE_USER_CHOSE" or something.
The system uses the title of the item, when that item was created. So if you open Path Finder/Contents/Resources/English.lproj/MainMenu.nib (in Interface Builder) and use the title it has there, it likely will work.
Disclaimer: the path is a guess, if it’s not that, it’s probably close.
but because it says that it can handle everything, and no other app says that,
I can't help thinking that this was no accident (i.e. no app is *supposed* to say it handles everything), but I'll shut up about it now.
Well, the reality of such purism would mean that each time someone needs to use TM with a language (i.e. file extension) I hadn’t previously heard about, that person would need to modify the Info.plist to make Finder allow dragging that file to TM etc. -- and likely write me to ask that the extension be included in future release.
[...] but maybe a Howto on manually disabling would be useful?
Yes, I’ve been wanting to write up a good “behind the scenes” working of all this stuff.
-
Allan Odgaard -
Rob McBroom