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.
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.
The recordSelector: might receive a ‘nil’ argument. Previously this was handled gracefully by using ‘dictionaryWithObjectsAndKeys:’ but not so when using the new Objective-C literal array syntax. So reverting to the old syntax.
This closes issue #38.
Use the text foreground color for icons when the theme doesn’t provide a color and introduce ‘gutterSelectionIcons’ for the color of selected icons (defaults to selected foreground color).
Also changed the gutter selection border color to match the divider color (when it isn’t specified by the theme).
Previous solution didn’t handle soft wrapped lines.
This solution also scales better, as we no longer need to break up ranges and create an entry per selected line.
All the settings are now taken exclusively from the property files, so no more user defaults. This means users will have to set their theme and font again.
Drawing the border did not account for auxiliary views (presently used by incremental search). See issue #240.
It also did not properly layout the views when adding/removing such views, causing the border to disappear after having used incremental search.
Theme was no longer initialized by OakTextView, instead we relied on OakDocumentView to provide us with a theme, but if the user had no themes installed, it would never do so, leading to a crash when OTV uses a theme member function to obtain colors.
This closes issue #222.
If caret is at the first position of a place holder then we no longer look for tab expansions, should the user press tab.
This address the issue where a placeholder has optional content and the word to the left of this optional content is a tab trigger. Previously deleting the placeholder text and pressing tab would insert a new snippet, which would generally not be expected.
This closes issue #226.
When two neighboring characters have different character class or one is an alpha numeric character (excl. underscore) and the other is not, we consider this a valid boundary for a tab trigger.
This closes issue #157.
When invoking an action that would replace the marked text (“CJK edit buffer”) with a zero-length string, we would continue to be in “CJK” mode and thus allow the input manager to process the next key press.
In this situation though pressing e.g. escape or backspace would result in the input manager inserting the literal character code for this key.
So we now leave “CJK edit mode” if the “edit buffer” is empty.
There is still an issue though where, if the edit buffer is not empty, and the user press backspace, we correctly (?) ask the input manager to handle this key press, but the input manager will (wrongly) replace the selection with the literal backspace character.
We have our own version of interpretKeyEvents: because we want to augment the default key bindings dictionaries (and support multi-stroke key bindings).
When there is marked text (as part of inserting CJK or similar) the system’s version of interpretKeyEvents: seems to handle key bindings slightly different, for example where ↩ is normally bound to insertNewline:, this might be suppressed when the user has just selected a “translation”.
