You can still create an alias for ‘mate’ that calls ‘mate --recent’.
The motivation for this change is that stuff you open via mate is generally SCM commit messages, the cron tab, included files (opened from within TextMate via bundle commands), and other such things. Additionally I think that if you open files via ‘mate’ you would just repeat the line in your shell, though I know not all users feel this way.
Folders opened via mate does go into the recent menu.
It’s not feasible to maintain the old-style xib translations while we work on the UI. We’ll soon move fully to constraint-based layout which should allow translations to be purely string-based.
Ideally I also wanted to include project directory, but since the user’s properties are read after the default ones, and those contain the setup of projectDirectory, this isn’t possible with the current semantics.
This changes the way the include/exclude keys work: A path now *must* be matched by an include key to actually be shown.
The default value of the global include key has been changed to include “*” but if users have edited the value, they will see few or no files in the file browser.
We now have:
- performBundleItem:
- performBundleItemWithUUIDString:
- performBundleItemWithUUIDStringFrom:
I’m leaning toward changing the prefix, as ‘perform’ is mainly action methods invoked as a direct response to some user action (with that action part of the name), but haven’t found a better prefix yet.
Both from code and the menus. These were not implemented and I see no real reason to implement freehanded movement as a toggle since it is easily obtainable via column selections or option-clicking beyond EOL.
Overwrite mode might be implemented, but rather low priority.
This is to allow a bundle item to display another key than the one assigned to the item, e.g. when the bundle item is matched by a proxy item it should show that item’s key equivalent.
This is specifically to find the actions bound to modifier + [, {, }, and ] before finding the actions bound to modifier + numbers, since on some keyboards, modifier + number results in one of the brace characters.
This should address issue #374 (although this isn’t a fix per se for the underlying problem of having some key maps result in duplicate keys in the menus).
This is mainly for TextMate’s own Open With menu, as it doesn’t seem to affect Finder’s (and TextMate already did support folders being dragged onto its application icon).
The scm::status::versioned status has now been removed.
The upshot of this is that SCM drivers can leave out files that are “clean” from their status map, and TextMate will assume they have status “none” (clean). This cuts down on the amount of data that needs to be sent (and/or processed) by the SCM drivers.
This is done by overloading performKeyEquivalent: for the main menu (by setting it to OakMainMenu in MainMenu.xib).
The default implementation of performKeyEquivalent: does not know about scope selectors so it will sometimes call the wrong actions. For example a bundle overloading ⌘X for “-dyn.selection” may still see the item fire with a selection.
This wasn’t a problem previously, as we set the key equivalents via (deprecated) Carbon API (so presumably Cocoa didn’t know about the keys).
This is a preliminary implementation, I just want it out there to have it tested for edge-cases. Long-term we can probably remove the overload of performKeyEquivalent: on OakTextView, which sort of does similar (stops Cocoa from executing the wrong menu actions or interfering with multi-stroke key bindings).
The recent move to 64 bit broke the (binary) protocol used between TextMate and the server for authenticated reads/writes (since size_t is now 64 bit).
This fixes issue #354.
Since we now use the (numeric) user ID as part of TextMate’s named socket (to allow multiple users on the same system to each run an instance of TextMate), mate needs to know this.
Running ‘mate’ via ‘sudo’ has getuid() return zero (root), hence why we need to specifically handle this.
The text encoding (or even field type) can be practically anything, so we need to either handle everything or coerce to UTF-8.
This is a quick fix for an issue with QuickCursor, a more thorough review of encoding used with AppleEvents is to follow.
