Both from code and the menus. These were not implemented and I see no real reason to implement freehanded movement as a toggle since it is easily obtainable via column selections or option-clicking beyond EOL.
Overwrite mode might be implemented, but rather low priority.
1. Removed the alpha channels from all images.
2. Deleted unnecessary double images. (@sorbits: You might want to
rename them to more accurately display what they do.)
3. Slight adjustments to improve the visibility of the bookmark icons
at lower font sizes.
The advantage is that we avoid creating an off-screen image for compositing. We want to avoid off-screen images as they may not use the same pixel format/density as the render context (screen).
This removes all the blending, the need to provide a scope selector to obtain them, and no longer taxes the general syntax highlight (by no longer having to carry around a dozen gutter styles per scope).
When we update the text view frame we implicitly cause the gutter to refresh, which will ask for line records from the text view based on the selection, so we should ensure the selection is up-to-date before changing frame size.
This is to allow a bundle item to display another key than the one assigned to the item, e.g. when the bundle item is matched by a proxy item it should show that item’s key equivalent.
On Mountain Lion the OS provides a colorWithCGColor: which tmColorWithCGColor: now wraps for (when available).
This fixes a warning when building with the 10.8 SDK.
We now load the image via NSImage and creates a CGImageRef from that (based on the current graphics context). This ensures we get the @2px version when on a HiDPI display.
We filter out items that doesn’t have the current prefix and deselect current item if the user deletes the selection.
Some of this logic should probably be encapsulated by a filterPrefixString property added to OakChoiceMenu. This will also avoid the visual flash which arise when filtering the menu and selection changes (since we do one redraw w/o any items selected).
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.
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.
