The reason for this is that NSTextField will draw itself in the “faded” state (for non-key windows) unless some of its parent views are marked opaque.
The previous problem with not having the parent views opaque (see da3a91a7bb) seems to have been solved by setting the autohidesScrollers property to YES.
Using instances with static storage in Objective-C files result in the following warning (starting with clang 425.0.24):
ld: warning: direct access in […] to global weak symbol […] means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
The symbol chooser is now owned by DocumentView instead of DocumentController.
The symbol chooser does not know about its owner and is not an observer of any notifications. Instead it has a property for “document” and one for “selectionString”. It is the owners job to update these properties (i.e. when switching document or changing the selection).
This isn’t ideal but better than a potential crash (following the next edit). A better solution will have to wait to a larger refactoring (which should also consider multiple editors working on the same buffer).
Closes#186.
When user drag-selects and moves mouse outside the viewport, we do not want to use ‘ensureSelectionIsInVisibleArea:’ because that method looks only on the selection, particularly the non-anchored end-point (and works differently for unanchored selections). Instead we want to scroll the point corresponding to the mouse position inside the viewport.
Fixes#475.
Since styles_for_scope effectively ignore the font parameters (and instead return styles based on the font parameters used when the cache entry was created) it is a better design to have theme_t own the font. This way, changing it can do the proper cache invalidation.
A minor downside is that we can now change the font of the theme without also changing the layout’s font, which wouldn’t cause proper layout invalidation — since layout_t owns theme_t though, users of a layout should always change font via layout_t (which will then change it in the theme).
Also, themes cannot be shared between views that wish to use different font settings.
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.
