This allows getting a variable from the global domain without any variable interpolation (for settings that use $variables or \escapes).
This is required to provide a UI for editing preferences values (here we want to edit the unexpanded value, and the version in the global domain).
All the settings are now taken exclusively from the property files, so no more user defaults. This means users will have to set their theme and font again.
Despite Menlo having been the new system font for fixed width text in the past several OS versions, NSFont’s userFixedPitchFontOfSize: still return Monaco, unless we build with the 10.8 SDK (and no, setting the deployment target to 10.7 does not produce something that actually runs on 10.7, at least not last I checked).
The disadvantage with Monaco as default font is that we lack bold and italic styles (since CoreText doesn’t synthesize these, unlike the legacy text rendering API TextMate 1.x used).
Instead of storing things in user defaults we will store them in ~/Library/Application Support/TextMate/Global.tmProperties.
This just makes things a lot easier than having to mix NSUserDefaults with our .tm_properties files, especially since changing a setting in the UI should sometimes be global, sometimes be for the current file’s type, and sometimes just for the current document (e.g. spelling language).
These features are already available with the .tm_properties.
Drawing the border did not account for auxiliary views (presently used by incremental search). See issue #240.
It also did not properly layout the views when adding/removing such views, causing the border to disappear after having used incremental search.
A minor caveat is that if there are encoding or newline (folder specific) settings in effect for the chosen path, these trump what’s selected in the save dialog.
If we wish to solve this, the best would be to update the options (shown in the save panel) based on selected folder/filename (and the settings in effect for that).
This closes issue #163.
We moved it to TMPDIR so that multiple instances of TextMate could run (for different users) but have since gotten a lot of reports about problems with this location. The short version is that ‘ls’ shows the socket exists (in TMPDIR), but stat’ing it or similar will fail.
To still allow different users to use mate side-by-side we add the user ID to the socket name.
Hopefully this closes issue #183.
The reason for this is that we might be able to overwrite mate even if we do not have write access to the parent directory. This will avoid us having to prompt the user for an admin password (when updating mate).
It should be mentioned though that incase mate is not a regular file, we do need to remove it first, because if e.g. it is a symbolic link, our install would write to where the link points to.
Theme was no longer initialized by OakTextView, instead we relied on OakDocumentView to provide us with a theme, but if the user had no themes installed, it would never do so, leading to a crash when OTV uses a theme member function to obtain colors.
This closes issue #222.
This was (temporarily) disallowed by previous commit. We do however need to allow it in the last placeholder since that is used for chaining snippets. See issue #182.
If caret is at the first position of a place holder then we no longer look for tab expansions, should the user press tab.
This address the issue where a placeholder has optional content and the word to the left of this optional content is a tab trigger. Previously deleting the placeholder text and pressing tab would insert a new snippet, which would generally not be expected.
This closes issue #226.
It can happen that we register the same value transformer twice, e.g. if we register it in an initialize method (since these are not guaranteed to only be called once).
This isn’t a problem per se, but there is no reason to create the new instance.
Previously we used ‘dealloc’ to release the array, which is wrong.
Since instances of OakStringListTransformer is normally never released this bug wasn’t affecting anything. But since we have a dealloc, it should be correct.
This will expand/collapse the find results.
The benefit here is just having a key to quickly collapse all the results so that we get a list of files (with matches).
This is to avoid running out of memory, ideally we would search in chunks, but given that Oniguruma has no direct support for this, such fix is more involved, and it’s likely rare people want to perform regular expression searches on files larger than 5 MB, so I feel this is sufficient to close issue #38.
