When opening SCM manager folder TM opens untitled document in the editor area and the target folder in file browser. When one sets `windowTitle` to display SCM branch this is not displayed for untitled document. So one needs to open some existing file first.
This change sets SCM variables also for untitled document as if it was saved in selected file browser folder, effectively showing current SCM branch.
This is done using an alert with an accessory view. Not the best user experience, but given how rarely the user interacts with this, I wasn’t really in the mood to spend a lot of time on this part now (can always be improved later).
Closes issue #200.
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).
For example Xcode projects now have their target (URL) set to xcodeproject://path/to/project/file which would cause Show Package Contents to not work, as it expected a file URL.
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).
__attribute__((format(...))) was added to NSAlert's class-based initializer in 10.7, and due to using string objects instead of literals as informative text, Clang is unable to guarantee the safety of the formatter, and, as such, issues a warning.
The problem is that we used to treat an empty status map as meaning we hadn’t yet requested status for this repository, however, now that we no longer need status for all files, we would have an empty status map for clean (svn) repositories, leading to needlessly requesting status updates all the time (and on main thread).
This can be used to make decisions about whether or not we should assign a virtual status to directories, prune them from a status display, or similar.
Subversion itself is roughly 30% faster if we do not ask for status of all files, the XML processing though is magnitudes faster, since it will only have to deal with a few records (in the general case) rather than a record per file (xsltproc seems to do around ~10,000 files per second on my Mac Pro, though I have no idea if it scales linearly).
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.
For a repository with 7,767 files it takes 3.5 seconds for Python to convert a full file listing from XML to the simpler line-based format. Using xsltproc the same takes 0.74 seconds.
According to issue #340 TextMate “freeze for up to about 5 - 10 minutes” when doing svn status. Not sure how much this change helps on that, no doubt it’s an improvement.
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).
This allows the SCM drivers to not report status for non-modified versioned files.
The problem was previously that if a driver didn’t report status for such files, having a file go from modified → clean wouldn’t always cause a refresh, since no change notification was generated for the path.
For the svn driver there is a 50% overhead by svn itself in reporting status for files without status, this overhead is likely magnified by the following XML step (where XML for all files in the working copy needs to be parsed).
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.
Turns out this is required in the situation where the document occupy less space than the visible document rect.
In this case, inserting new lines will not resize the text view, since it has been artificially enlarged to fit the visible document rect, therefore the gutter view will not update properly when inserting new lines.
I think there is a better solution than have the text view refresh the gutter, reverting is just meant as a quick fix.
This reverts commit 4e2ae3c508.
This is a fairly subtle bug: We were implicitly creating a temporary std::string object and requesting c_str from this object.
This C string’s lifetime was that of the temporary std::string, and as we did a lot of std::string creation in the following line, with the new libc++, there was a good chance that the temporary string buffer would be re-used and so, our working directory would be set to a bogus value.
This closes issue #329.
Renamed the DialogPopupMenuTarget class to avoid a run-time warning logged in Console.
Users will sometimes quote stuff from Console in bug reports, so let’s cut down the noise.
1. Default SDK set to 10.8 (since we now use subscript operators).
3. Version is tagged (by default) with “-git”. Not too happy about this, but I need a way to filter out “build from source” when analyzing crashes and similar. I’ll revise the solution later.
2. Revision only taken from api.textmate.org (no git fallback).
4. Only multimarkdown is a valid markdown compiler (due to recent changes in `bin/gen_html`).
I suspect that this was added because some operations were not properly detected, though the only thing I can find, that doesn’t properly update the gutter, is when deleting folded code in a way that doesn’t change the bounds of the text view. This code however does not address that issue.
Incase the last line of a file is folded (has no newline) then the gutter would first receive a row record for the line starting this fold, and then when querying for the next row, it would get the last line of the layout, this had a different line number but shared same coordinates as the previously rendered line, so the gutter would draw on top of that.
Closes issue #256.
