A file setting like “src/*.cc” is arguably more specific (and thus more local) than targeting the scope “source.c++”, so it makes sense that the file settings rank higher than scope settings.
Some users also find it natural to target file extensions over scopes, but as TM will store some learned settings with a scope selector, it would previously lead to confusion, when a user was unable to e.g. change tab size for “*.php” (because TM had a learned setting for “source.php”).
This setting allows changing which invisibles are shown and what glyph
is used for them.
Invisibles are '\t', '\n', and ' ', to turn one off, add ~[\t \n] to
the settings string. To set the glyph used for the invisible, add [\t
\n][glyph_to_use].
We keep indirect references to cache lookups (for the duration of the function that use the cache) so we can only do cleanup at the start or end of the function which use the cache.
This applies both to the action method and the settings key, the latter is now relatedFilePath to indicate that it’s a full absolute path (neither relative or a glob pattern).
The user can now set ‘counterpart’ in .tm_properties to the absolute path of what should be used for ⌥⌘↑. If the file does not exist (on disk or as an open tab) then TextMate will fallback to searching the current folder for a file with same name.
To switch between go source and go test files one could add the following:
[ *.go ]
counterpart = "${TM_FILEPATH/(_test)?\.go$/${1:?:_test}.go/}"
Here the regular expression transformation will remove ‘_test’ from the file name if it exists, otherwise add it.
One could also do multiple settings like:
[ *.go ]
counterpart = "${TM_FILEPATH/(?=\.go$)/_test/}"
[ *_test.go ]
counterpart = "${TM_FILEPATH/_test(?=\.go$)//}"
Here ‘*.go’ files get the ‘_test’ added to their name, though files matched by the ‘*_test.go’ glob will instead have it removed.
Set this to ‘true’ if you want the file chooser (⌘T) to follow symbolic links.
The reason for making it a ‘.tm_properties’ setting is only because I am not yet sure how to best integrate this into the UI. The find dialog has an identical UI option which is global option — it would make sense to coalesce these two options, and while doing that, make the find dialog’s version a project/path setting rather than have it be global.
Closes#984.
This was previously public so that we could write tests for it, but since the test runner is linked with the object files, it can access symbols that has visibility set to hidden.
This will be a colon-separated list of the .tm_properties files sourced for the current context. Mainly for debug purposes but could be used for an “Edit Properties…” command that show existing files (without having to scan the disk).
We generally lookup include/exclude patterns for a folder rather than a file, and here it makes sense to allow the bracketed sections of the property files to target the folder.
Since the sections are not ranked based on how good a match they are, targeting a subfolder, and then a subfolder of this subfolder, does not have which settings take precedence defined.
Disabling this is achieved by setting `fileBrowserDocumentStatus` to `false` in `.tm_properties`.
Disabling it should remove potential delays after opening, closing, and saving files when file browser is showing a lot of files. It is meant as a temporary workaround until the performance issues are addressed.
This is so that a global setting for ‘source.ruby’ takes precedence over a local ‘source’ setting.
A minor downside is that a local properties file cannot use scoped settings outside a scope selector section.
This is for bundles that need to read TextMate’s preferences file (should only be those using a nib with user defaults bindings for their preferences dialog).
Unfortunately a printf precision specifier (‘%.*s’) can not come with a width specifier so we have to cast to int. The width specifier ‘t’ is used for ptrdiff_t.
The int → NSInteger change fixed a bug with popup menu positioning, but there was no associated warning or error. It's possible there are more such bugs that we haven't found yet!
Mainly this is because when we run tests, we do not want global or default settings from TextMate, so now TextMate.app explicitly sets the path to the default and global settings (unlike when running tests).
If we only provide key and value, we set the setting globally.
If we provide an additional file type, we set it for that file type and parent file types (i.e. “text” is parent of “text.plain”) plus globally. An exception is when we give an “attr” scope as file type (then we do not cascade upward).
If we provide a path / glob, we set it for that path / glob and, as file type we can provide NULL_STR to limit it to just that path / glob, the empty string ("") to also set it globally, or a file type (which is treated as above).
Used in tmProperties this is to target untitled files, files with unknown encoding, and similar, so unlike text or source scopes, we do not want to set the option broader than the exact scope.
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).
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.
If we set projectDirectory to a non-path (e.g. ‘dummy’) then that value makes it into the default folder to search (on ⇧⌘F). Since we want folder specific settings for the path we are about to search (include/exclude patterns) then we would ask for settings for a non-path, which the settings framework couldn’t handle (it kept asking for the parent of this non-path expecting to eventually get to either the user’s home folder or the root of the disk, but instead it would loop infinitely).
This fixes issue #19.
Previously this was under the OakSystem framework which depends on the io framework meaning that the io framework itself was unable to obtain a basic environment, which is necessary for next commit.
