TextMate highlights certain character pairs (e.g. { }) when the caret passes over either of the characters. It can be useful to double click to select the text in between and including the character pairs for deleting code, copying code, for visually differentiating the affected code, etc. Add a select_unit_type, kSelectionExtendToWordOrTypingPair, to select the inclusive bounds of a typing pair if a match is found, or otherwise select a word as normal.
This patch is free and released into the public domain.
It's possible that the path on the document is set even though it does not exist on disk. E.g., when using `mate` to create a new document from the command line.
It seems that the "showDefinitionForAttributedString:" can accept a nil argument, but not an empty string. The inserted test is preventing the call when the extracted string contains no characters.
This was done in an attempt to prevent the warning saying “This file is set to build for a version older than the project deployment target.”
Unfortunately saving all the xibs did not get rid of the warning, even though tehy are all set to have 10.7 as their build target.
The latest xib format does however remove about 10.000 lines of XML.
This is because we were forwarding the message to ‘nil’ rather than the status bar, and ‘nil’ here would be first responder, i.e. ourself.
Fixestextmate/bugs#17
I’m seeing a few crashes where the most likely explanation is that input client methods are called either before setting up an editor instance, or after disposing it.
The auto-calculated key view loop includes everything, which means dynamically added elements such as the close buttons for tab view items, but worse, the subviews of a view-based table view. So this change is required before switching to a view-based file browser.
If you dislike the downscaling of the line numbers then run the following in a terminal:
defaults write com.macromates.TextMate.preview lineNumberScaleFactor -float 1
If there are multiple (discontinuous) selections then this action will drop the last one.
If there are multiple carets (with no selections) then this action will drop all but the first caret.
When command-clicking an existing selection we remove the selection and insert a single caret.
When double/triple-clicking we remove existing carets/selections in the range that gets selected.
The problem is that when something is saved, the text view is responsible for invoking the callbacks, but it might not show the document that was saved (e.g. in the case of Save All where background tabs are saved).
Long-term this should be improved so that OakTextView is not responsible for executing these commands; the challenge is that OakTextView supply a lot of the environment (like some of the TM variables), potentially the input, and is also the potentially receiver of the output.
This broke when we changed from insertText: → insertText:replacementRange: as the latter selector is not replayable.
We now record this action simply as insertText: and ignore the “replacementRange” argument. This argument can be used by advanced input managers, so there might be an issue with text recorded using such manager, however, to properly support this we need to translate the “replacementRange” into something relative, which is left as an exercise for a rainy day.
