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.
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 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.
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.
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.
There is a somewhat frequent crash caused by infinite “did resize” notifications. It’s unclear exactly why this happens, but basically a subview shouldn’t resize itself unless asked, and it shouldn’t resize siblings either.
We now have an explicit sizeToFit which takes care of sizing the gutter view. It is the responsibility of the owner (of this gutter view) to resize the gutter’s parent scroll view and any siblings that may need adjustment (after calling sizeToFit).
Additionally it is the responsibility of the owner to call sizeToFit when there is a chance the gutter view size needs updating. Generally though, the owner should know, as it is the data source for everything.
Previously we would lock focus on our source image. This is bad because we do rasterization (to a fixed pixel format / density) and it (potentially) destroys / mutates the source image.
We now use a second (new) image for the compositing. This is still not ideal, as this second image still is “off screen” so lack the proper graphics context during rendering. A better approach might be to create a CGImage using the graphics context and use that as an (image) mask and do a stroke, but this would require the images to be changed and I am not really certain it will work.
I am seeing crash reports from resolve_links and I can’t think of any other reason for this crash, than readlink() returning a value which is neither -1 nor in the range [0..len].
We now leave a potential trailing slash in the result.
This fixes the issue of the missing slash in ⌘T — while I normally prefer the slash to be stripped, I think path::with_tilde should be an exception since effectively it is just replacing the path prefix, it shouldn’t do any real processing (although we do actually normalize the string).
Also fix a bug where we would use tilde for paths pointing to a user folder for a user with current user’s name as prefix.
Variables customizing `windowTitle` such as `$TM_SCM_BRANCH` can change while TM is inactive, while user is working in command line or different app. So it is better to refresh `windowTitle` once we get back to TM.
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!
As we are no longer using Carbon functions to set menu key equivalents, this means that bundle menu items which have the same key equivalents as main menu items will unfortunately not display their key equivalents in the menu.
