Not only do we test for the presence of these functions at runtime, but we do not use them at all, when building with the 10.11 SDK (or earlier).
This is because if we had to support building with an earlier SDK it is not enough to declare the prototypes, we also need to add the symbols as weak to the linker options.
Not using the functions does not remove crucial functionality.
The algorithm to calculate exact rank requires n × m storage which is stack allocated, so for large strings, we could blow the stack.
Rather than switch to dynamic allocation, we’re just foregoing the exact rank, since for large strings, it’s unlikely to be useful to try to calculate such a thing.
Versions of the OS X 10.11 SDK prior to 10.11.4 require this to
be done explicitly. This fixes the build on OS X 10.10 when
using the OS X 10.11 SDK from Xcode 7.2.1 and earlier.
When all paths had the same prefix as first item, the first item would be returned as the common ancestor even if the other paths were not children.
For example:
/path/to/some_folder
/path/to/some_folder_with_same_prefix
Here `/path/to/some_folder` was returned even though `/path/to` is the common ancestor.
The function is still not correct when all paths are actual descendants of first path, but since it’s only used for display purposes, and with “find in folder” (where paths shouldn’t overlap), I am not bothering with that issue.
Previously this database was loaded each time a file of unknown encoding was read, which could add a significant overhead when using “find in folder” with a large database and many files with unknown encoding.
The reason is that menuForEvent: will draw an outline around the items under the mouse, which can be incorrect when we use the keyboard.
While we can address it by creating a fake mouse event that points to the selection, this will fail when there is no selection, so I felt it was better to always forego it.
Comment also added to the source (since this workaround is not optimal, and I would like to find the correct solution):
If we use `self.size` for the off-screen image buffer then we get a scaled up 16×16 image in the file chooser (⌘T).
My theory is that when drawing the image, the image size is 16×16 but the graphics context uses a transformation so that each point is multiple pixels, which our off-screen image does not replicate.
I do not know how to get the actual “pixel size” of the destination, so using the largest image is a workaround and knowing the actual size could give a better result.
- number: Show number with thousand separators, e.g. “32,351”
- relative: Show dates as relative to now, e.g. “3 minutes ago”
- duration: Show numbers as duration in seconds, e.g. “1 hour, 7 minutes”.
- dirname: Show all but last path component
- basename: Show last path component
- urlescape: Encode characters that are not valid to include in URLs
- shellescape: Wrap problematic strings in single quotes and/or escape single quote characters
There were two issues:
1. The window’s sheetParent property is cleared when sending orderOut: to the window so the NSModalResponse was never passed on, as we were sending it to nil.
2. The endSheet:returnCode: was using NSModalResponseCancel but the completion handler was actually testing for NSModalResponseAbort
We were already using the triangular bullet in a few places, so I made it consistent. Semantically the small triangle might be more appropriate, because we do not use the glyph as a point marker, but I think the triangular bullet aligns better with the text (it’s raised above the baseline where the triangle seems to just touch the baseline).
This is done by setting the ‘disableJavaScriptAPI’ key to ‘true’ in the tmCommand file.
The rationale behind this is that a command like “HTML → Show Preview” is using the HTML output view with user data which should not have access to the special TextMate JavaScript object, for example a user may have a `<script>` tag that loads JavaScript from a CDN, and such script would effectively have shell access to the user’s machine.
