Removed the ability to specify wether documents should open in current window or a new window — all documents opened via this API will go through the same algorithm to find where the documents should end up (more choice is just adding confusion and complexity).
We may use OakDocumentView in a context where we don’t immediately assign it a document, or we wish to “overwrite” its default document with an untitled document that we create.
If the document view holds its own untitled document then the global counter includes that and the one we create is one higher than expected.
Seeing a few crashes related to CFRetain() called from CTFontCreateWithName(). My guess is that a nil font results from a bad/corrupted config file, so the actual fix might be to ensure we have a font (at a higher level).
There are crash reports showing the gutter view accessing its datasource in OakDocumentView’s dealloc (based on a “bounds did change” notification fired when releasing a view).
We now explicitly disable it for targets that hasn’t yet been upgraded to ARC. This way, it’s easier to get an overview of which targets hasn’t yet been upgraded and ensures new targets has ARC enabled.
This is only motivated by easier transition to ARC (one framework at a time) as the ns/attr_string.h header contains manual memory management, which thus cannot be included by a framework using ARC, yet the code needs to be in the header since the code is template-based.
Zoom is an OS X accessibility feature that lets sighted visually
impaired users magnify screen content. This commit notifies Zoom of
changes of TextMate’s caret position on screen so that Zoom can
automatically follow the caret when the user moves it.
This commit adds support for most common accessibility
methods/attributes to the OakTextView component. In user's language,
VoiceOver users (i.e. blind and visually impaired users) can now use
TextMate to read and write text.
A few less used accessibility attributes remain to be supported -
especially AttributedStringForRange and StyleRangeForIndex which should
allow blind users to e.g. see and seek for spelling errors in text.
Commands can prepare the document for saving in this callback, e.g. strip trailing whitespace (issue #35), ensure the line always has a newline character as the last byte in the document (issue #76), or similar.
Presently having a “will-save” command fail does not abort saving (but likely should). Also, there is no check to see if the command called requires the document to be saved before running, so that likely leads to an infinite loop.
The text view needs to do a little work before saving a document (serialize folded text) and with the window as part of the user data, we can now skip that for text views in windows for which documents are not going to be saved.
This is not an ideal solution; long-term saving will be moved up to the DocumentWindowController which has the full view of all documents and text views.
The methods going to “begin of indented line” will go to the first non-whitespace character on the line, unless the caret is already there or to the left of this character, in which case it will go to the actual beginning of the line.
The “end of indented line” methods work similarly.
If you want [⇪]⌘⇠/⇢ and ⌘⌫/⌦ to use this behavior, you can add the following to your key bindings file:
"@\UF702" = "moveToBeginningOfIndentedLine:";
"$@\UF702" = "moveToBeginningOfIndentedLineAndModifySelection:";
"@\UF703" = "moveToEndOfIndentedLine:";
"$@\UF703" = "moveToEndOfIndentedLineAndModifySelection:";
"@\U007F" = "deleteToBeginningOfIndentedLine:";
"@\UF728" = "deleteToEndOfIndentedLine:";
Command-clicking an existing caret normally toggles, unless there only is a single caret, in which case it adds a caret. This would thus allow you to add a new caret sharing the position of the existing, and command-clicking again would then remove both the two existing carets, leading to an assertion failure (as there were no carets).
Fixes issue #466.
There are several crashes reported from firstRectForCharacterRange: which indicate that the system may ask for indexes “out of range”, hence why we now effectively just cap such request.
The refresh helper uses the document’s undo manager in its destructor. Normally the document would stay open throughout the duration of the scope in which the refresh helper is used, but it might be possible to close the current document from a nested event loop, as spawned e.g. by showing a tool tip, in which case, the document will be closed when we reach the destructor.
It’s not feasible to maintain the old-style xib translations while we work on the UI. We’ll soon move fully to constraint-based layout which should allow translations to be purely string-based.
The gutter will invalidate its intrinsic size when its width changes which will cause the Cocoa layout engine to update the layout, so no more explicit code to deal with adjusting the gutter’s width.
Likewise, the height of the gutter (not the gutter scroll view) has been setup to match the height of the text view (again, not the containing scroll view). This avoids observing the text view frame and manually updating gutter height to match it.
There’s a few subtle advantages of going with a view, mostly theoretical (about minimizing refresh rectangles) but switching to constrained based layout should provide minor code simplifications, since our ancestor view won’t have to deal with the gutter divider rectangle.
