This post is meant to clarify a few Leopard related issues.
Quick Look is the technology which allows you to preview your files in the Finder. Some assume that because they see a TextMate document icon for a file type, it is TextMate’s responsibility to “make it work” for that file type, so let me clarify.
The way the system works is by having Quick Look generators be able to generate the preview for a specific file type. By default there is such a generator for Text, more specifically
The reason this is not used for «your file type» is that the system does not know that «your file type» conforms to
The way the system learns about file types is by looking in the
Info.plist of the installed applications. So ideally TextMate would contain info to educate the system about the file types you use with TextMate. Adam R. Maxwell posted a small utility to update TextMate’s
Info.plist with the document types assigned to TextMate (and declare them
public.plain-text). There is also a MacOSX hint about updating TeXShop to contain UTI info about LaTeX.
Naturally it should not fall upon the user to manage all the type information. The reason that I haven’t added UTI info to TextMate yet is twofold, 1) it is a major cataloging work adding proper type info for all the types TextMate currently claims to support (there are more than 100 different extensions in the current
Info.plist) and 2) the proper type info means having markup languages conform to
public.plain-text, and so, would actually not be handled by the Quick Look generator for Text (I wrote a longer post about this).
I have received a lot of bug reports related to how windows act in Spaces, how they can or cannot be moved between spaces, etc. Generally though this is outside the domain of a user application and bug/enhancement reports should be entered into Apple’s Bug Tracker.
There is one item which might be up for debate, namely that re-opening a window (like the Find window) opens in the last space where that window was used. Now again, the concept of spaces is unknown to user applications, so there is no way TextMate can explicitly tell the system which space that window should open in.
Update: Joe Ranieri informs me that there actually is API for this. An update will be out soon where the Find window does follow the active space.
The reason e.g. TextEdit does not show the same problem (for the Find window) is that TextEdit will re-create the window when it is needed, and creating a new window will have it open in the current space, where re-opening a window, has it stick to the space where it was last open in. That is, unless the window is a utility window, as Thomas Aylott explains in his tip on how to make Safari’s download window follow the active space. You could argue that TextMate thus should re-create rather than re-use its Find window to be a better fit for the current semantics of Spaces, but for now I am waiting to see if Apple doesn’t change this behavior, since following the active space is really what you want for all windows, and switching to re-creating windows, rather than re-opening, is not flipping a switch, since you generally want to preserve the state of the window when re-opening it, e.g. open Preferences, switch to the non-default page, give focus to some control, now close and re-open the window, if the application was to dispose and re-create the window, this state would be lost (and AHIG says it should be kept).
After the release of Leopard I had a handful of reports of a detached drawer. Florian Gilcher though says he also saw this on Tiger and mentions that it is likely to happen in relation to switching monitor setup, so it might just have been a fluke, that the number of reported incidents rose, or it might be, that this problem is more prevalent on Leopard.
There has previously been reported problems related to switching monitor setup (i.e. going from two → one attached monitor) and window behavior.
Like with Spaces, for regular applications that do not mess with low-level window stuff, these problems are rarely caused by the application itself.
mate Shell Command
Two problems commonly reported after upgrading to Leopard are:
I lost the
mateshell command, how do I get it back?
The answer here is to select Terminal Usage… from the Help menu.
I get this error:
mate: failed to establish connection with TextMate.
The shell command uses Distributed Objects to talk with TextMate. For reasons unknown to me, Leopard’s version of
screenmakes clients unable to connect to the server. Andre Arko found that if you install
screenfrom MacPorts, the problem goes away.
Page Up/Down Weirdness
A couple of users reported that page up/down behaved really weird. The solution was to delete
~/Library/Preferences/.GlobalPreferences.plist. This file holds a minimal number of global settings, you can open the file in TextMate and press ⌃⇧H to inspect these before you zap the file.
No Gear Menu on Control-Escape (⌃⎋)
This is caused by having enabled Screen Sharing or Remote Management in System Preferences → Sharing. This was also a problem under Tiger (with Apple Remote Desktop), but now that ARD is built-in, it is more prevalent. I am not sure why ARD needs to intercept this key combination.
Speaking of the gear menu, the items with tab triggers are using a larger font than regular items — I am aware of this, but haven’t looked into it yet.
KeyBindings.dict Entries not Working
When you press a key the generated event is first passed to the menu system and then later the control with focus (i.e. the text editing area in TextMate). It is the latter which resolve keys based on your custom key bindings, where the former will resolve keys based on the key equivalents given to the menu items.
In Tiger the menu system would only resolve key equivalents for menu items with the ⌘ modifier. In Leopard it also handles those without this modifier, so if you have bound ⌃T to some action in your key bindings file, in Tiger that action would be executed, but in Leopard the menu system will see that Text → Convert → Transpose has ⌃T as key equivalent and so will execute that menu item.
To work around this you need to assign another key equivalent (using System Preferences → Keyboard & Mouse) to the menu item which eclipse your custom key binding.
In the past when people experienced broken rendering the tip was to reset the font cache. With Leopard this is slightly more involved.