shysaur/fragaria

Cocoa syntax highlighting text view

fragaria's Issues

Replace hidden glyph visualization code

I feel like the way hidden glyphs are made visible is currently a bit hacky. But, from Apple's documentation, how one is supposed to implement this feature in the right way is not clear. Plus, none of Apple's apps which use Cocoa's text system implement this feature (iWork has its own CoreText based text system), which is telling of what Apple thinks about it...

Currently, at the end of the layout process, SMLLayoutManager searches for invisible characters and draws (with CoreText) a visible character overlapping them.

I'm going to remove the (already disabled) code in SMLLayoutManager and MGSGlyphGenerator which tries to implement this feature by glyph substitution at the glyph generation phase because it's not going to work ever.

The text system relies on having NSGlyphGenerator produce special glyphs for line breaks, tabs and spaces, and replacing them with any other character will break the layout phase (tabs will no longer tab, line breaks will no longer break lines, and I even managed to lock NSATSTypesetter in an infinite loop searching for hypenation points by trying to make this approach work).

I tried to reimplement hidden glyph visualization by subclassing NSATSTypesetter and replacing control glyphs with visible glyphs during the layout phase, which is how hyphens are added when automatic hyphenation is enabled. Basically, I let the typesetter do its work (laying out unmodified glyphs), then each invisible control glyph is replaced with a visible glyph. Since the replacement takes place after the original glyph has been laid out, the replacement glyph gets the same position as the invisible glyph, and no custom drawing is needed.

This works very very well, and requires very very little code (I don't know if it's faster, but it's certainly comparable with the current approach).

But there's an issue: since attributes can't be overridden by the typesetter, the substituted visible glyphs have the same attributes as the surrounding text, which is obviously correct, but we have this feature where invisible glyphs are set a different color, which has some value (TextWrangler has it, for example). This feature can be easily restored by adding a syntax coloring pass which always executes and colors invisible glyphs, but that would probably slow down SMLSyntaxColouring even further.

So, summing up everything, there's no real advantage in the newer code... The new implementation is in the rewrite-invisibles branch (look at MGSTypesetter.m). @balthisar, what do you think?

Breakpoints API is limiting

With the current API, one can't modify breakpoints programmatically (every breakpoint edit must go through the user). A better alternative would be a syntaxError-style API. This would also offload breakpoint handling from the gutter view to a separate class.

Reconsider document body icons and the current gutter view

Are you willing to sacrifice the in-body error buttons in favor of this:

• display errors only in the gutter.
• eliminate the reference to "line number gutter" (now it's just the gutter)
• maintain the ability to toggle the gutter display on and off
• the gutter now has a property indicating whether or not it will display line numbers.
• can add a property to Fragaria (probably to the new error controller) that will turn the gutter on automatically if there are any current errors (user default preference).

I understand the point about the delegates in #13, but there's one crucial thing I didn't mention at the end of the issue report: it wouldn't work with the body icon.

Right now the errors buttons are implemented two distinct ways:

• In the highlighter. All errors in the visible range are drawn in the document body at once, and I can't think of a way that a delegate would be efficient here.
• Separately in the ruler. In the second case, error icons are added in the gutter only when the line is drawn, and really in the same manner as the breakpoints.

The gutter has no reason to know about errors; it only has to know what to draw. In this respect icons in the gutter are just another decoration, like the breakpoints, and this would be an appropriate use of a delegate if I understood your explanation correctly.

Previously in the document body if line wrap is turned off and the lines are long, the warnings were not visible unless the user scrolls horizontally. I inserted a change to push them to the left of the text view to prevent this when line wrap is off, but the appearance on screen is ugly there ("better than nothing" is the only defense I can offer).

So my thought was to eliminate them from the text editor completely and display them only in the gutter. Of course this would mean that the icons are not visible with line numbers off, but then again, neither are the breakpoint markers currently.

Looking at Xcode and most other text editors, the norm is that there's always a gutter, and the option to display or not display line numbers happens within the gutter.

I won't make begin making a change this drastic unless you decide it's worth sacrificing the body error icon.

Autocomplete only when selecting a value from the suggestions list?

Is it possible to make the autocomplete functionality update the text in the editor only after I manually select a option from the suggestion list and press Enter?

Currently, for example, in SQL mode when I start typing "sel" the "SELECT" keyword appears in the suggestions list, is automatically selected and the current word in the editor changes from "sel" to "SELECT". The only way to revert back to the original text is to press Escape to hide the suggestions list.

What I need is the text to change only after I manually selected the desired option (SELECT in this case) and pressed Enter (or selected it with the mouse).

Scrolling is stuck after changing layout

Hi!
Thanks for this awesome live fork! I'm trying to build something cool using it.
Here's the only thing I spotted: after changing lineWrap or showsGutter, i.e. properties causing text reflow, scrolling is sometimes stuck in the middle of text (it doesn't go below it), the other part of text is cut off. It's not stable, however happens quite often for me. It looks like content height is not recalculated. After making any change, or selecting, or resizing the window, it comes back to normal.
Video example: https://monosnap.com/file/FnkL3axSRym2iwStJ06Zqo04UiJfPu
This also happens on Fragaria Prefs example app included into your project, built without any changes.
My environment:

• macOS High Sierra 10.13.2
• Darwin 17.3.0 Darwin Kernel Version 17.3.0: Thu Nov 9 18:09:22 PST 2017; root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
• Apple Swift version 4.0.3 (swiftlang-900.0.74.1 clang-900.0.39.2)
• Apple LLVM version 9.0.0 (clang-900.0.39.2)
• Target: x86_64-apple-macosx10.9

After some investigation I noticed that adding

[[self layoutManager] ensureLayoutForTextContainer:textContainer];

in SMLTextView::updateLineWrap, after:

[[self layoutManager] textContainerChangedGeometry:textContainer];

fixes the issue, but I haven't checked it completely yet.

Documentation is absent

Updating header files with appledoc/headerdoc-compatible comments is a thing to do.

Also, these comments are also supported by Xcode for user-defined quick documentation.

Hidden errors are displayed anyway

The hideWarning property of SMLSyntaxError is not always observed when creating highlights and buttons.

Image cleanup

Currently, image resources in Fragaria are of varying quality and origin. They should be redrawn/updated to be all consistent with each other and in line with Yosemite's aesthetic.

Remove currentInstance:

First responders were invented for that, we don't need to duplicate that functionality.

Currently it is used by global text performers or menu controllers to access the Fragaria instance they have to work on, which is ugly as best. The functionality implemented by these classes has to be rolled into SMLTextView (editing stuff pertains to views, as evidenced by NSResponder's class methods).

Color well enabling does not work if the associated "coloursX" property is on global scope

In the current MGSFragariaViewModern example, the Attributes color well is an example of this misbehavior.

Make gutter always visible

Disabling the gutter makes the breakpoints feature unusable. The preference for disabling the gutter should be modified to a preference to toggle line numbers only.

Remove docSpecs

Originally, docSpecs were used to persist document state. But there are far less painful alternatives.

• Under ARC, usage of docSpecs basically create a circular retain cycle on all of Fragaria's internal objects, which can be solved only by sprinkling __weaks all around, and that's not good by definition.
• DocSpecs makes even interacting with other objects a pain: every time you have to get an object you have to make call objectForKey:MGSVeryLongAndSpammyConstant or valueForKey:MGSVeryLongAndSpammyConstant.
• They are exposed, and thus their original raison d'etre has vanished.
• DocSpecs flatten the entire object graph. This would be enough of a reason by itself to get rid of them.

The ideal "replacement" is to analyze the current object dependencies and then to make explicit ivars for object references. Then, the existence of docSpecs can be simulated (for backcompat purposes) by reimplementing objectForKey: and setObject:forKey: and the docSpec accessor in MGSFragaria. setDocSpec: should be reimplemented to log out an error, since I don't think anybody actually used it.

Also, the header for MGSFragaria exposes a lot of stuff about the creation of docSpecs and some stuff for accessing the content of a docSpec to make up for docSpecs being NSMutableDictionaries instead of custom objects. This stuff has to be removed (or stubbed out) as well, maybe in a MGSBackcompat category.

Hand-editable color themes

I think that color themes should be easily editable by hand with a text editor, so it would be nice to replace archived NSColors with @"%f %f %f" RGB triplets.

Podspec

Hi, as this seems to be the best available fork of Fragaria, you may want to consider adding a Podspec for it on Cocoapods. Just a thought :)

Allow registering in the global preferences controller

This makes easier to have a single preferences controller for every MGSFragariaView in an application.

Preferences groups should not retain the Fragarias they contain

Since preferences groups are never deallocated, forgetting to remove a Fragaria from a window when its window closes will effectively cause a leakage of that Fragaria (nobody is left to remove it from the group). It's more an inconvenience to Fragaria users than a bug.

This should be easy to fix; just replace the managedInstances set with an NSHashTable.

Line spacing

Perhaps we should add another property to allow for customizable leading in the view.

10.14/Mojave Dark Mode doesn't change appearance

I'll take a stab at this in the near future, as I've not contributed anything useful in a few years, and I still use this fork because it's pretty much the best thing out there.

I just wonder what we'd want to do with MGSPrefsColourProperties.xib and schemes. Apple's new guidelines suggest that WYSIWYG content should not switch automatically, e.g., a word processor should continue to show a white page. Fragaria isn't WYSIWYG, however, so I don't think that applies.

Ideally, I would think that we'd want to allow users to select separate schemes for Light Mode and Dark mode, so that the views update any time the system is changed, rather than forcing users to make a different selection.

If that's the case, we could leave the NIB alone, and update two preferences: if the user is in Light Mode and selects a theme or makes changes, then those colors are saved as Light Mode preferences. If the user is in Dark Mode, then colors are saved as Dark Mode prefs.

Alternatively, we could add another drop down list, and say that that's the selected theme for Dark Mode. This kind of complicates the UI, though, because when using the color pickers, which theme list is it applying to?

There's that, and also the gutter that doesn't take the Dark Mode appearance, of course.

Syntax Highlighter strings "spill out" from comments

Suppose you have multiline strings enabled and a single line comment like this (ObjC syntax def):

//test "comment
not a string"

Fragaria will happily highlight the false string fragment after the comment.

This is because the highlighter blindly colors strings first, and then it colors over the comments. The false string is fully colored first, then the comment parser erases the first section of the coloring of the false string and leaves the rest unchanged.

References frameworks are missing '@rpath/Fragaria.framework'

I have feed back from apple review

Your app references frameworks which are missing. This may lead to unexpected bugs or undefined behavior. The missing framework is '@rpath/Fragaria.framework'

We discovered one or more bugs in your app when reviewed on Mac running macOS 10.12

It's work very well on OSX 10.11.
I don't have macOS Seirra for testing! I think the problem is on new macOS , anybody experienced this issue?

Thanks

DIFF highlighting (feature request)

I'll look into this myself, too, as I have some time but I wanted to capture it here for discussion.

Currently SMLSyntaxColouringDelegate offers delegates for syntax groups allowing applications to customize the coloring of groups (i.e., the attributes, strings, etc.). However a line-by-line delegate method would be useful, too. Although I have in mind the specific case of highlighting diff results, I'm sure other line-based custom highlighting cases can be found.

Adding to the existing delegate seems like the logical place and would allow the application to pass back a block providing any arbitrary styling desired for the line while keeping Fragaria light-weight.

(Alternatively it could be handled similar to the error icons with a dedicated delegate, but this might limit the styling that can be applied without making Fragaria too heavy in an effort to be universal.)

Something like:

fragariaDocument:shouldColorLine:withBlock:
and
fragariaDocument:didColourLine:withBlock

I've not worked with Fragaria's internals since early this year so I don't know how aware the syntax highlighter is of individual lines. It's something I will dig into when I have a chance unless someone beats me to it.

Menus are inconsistent

Many standard NSTextView/NSResponder menu items are enabled while they have no effect or make no sense. In particular, this makes Fragaria's context menu 100% useless.

Can't select and delete all test - exception raised

I've not tracked it down yet as I'm buried in the SMLTextView and don't want to leave it broken, but right now if I try to select all text and hit backspace or delete, as of a8ae55c:

2015-02-28 23:18:34.234 MGSFragariaView[85233:52385397] An uncaught exception was raised
2015-02-28 23:18:34.234 MGSFragariaView[85233:52385397] *** -[__NSArrayM objectAtIndex:]: index 5 beyond bounds [0 .. 0]
2015-02-28 23:18:34.238 MGSFragariaView[85233:52385397] (
    0   CoreFoundation                      0x00007fff8c75066c __exceptionPreprocess + 172
    1   libobjc.A.dylib                     0x00007fff8a8a376e objc_exception_throw + 43
    2   CoreFoundation                      0x00007fff8c61adf4 -[__NSArrayM objectAtIndex:] + 260
    3   MGSFragaria                         0x0000000100040305 -[MGSLineNumberView wholeLineRectForLine:] + 789
    4   MGSFragaria                         0x0000000100041371 -[MGSLineNumberView decorationRectOfLine:] + 353
    5   MGSFragaria                         0x000000010003eaf1 -[MGSLineNumberView decorationColumnWidth] + 513
    6   MGSFragaria                         0x000000010003e811 -[MGSLineNumberView requiredThickness] + 593
    7   AppKit                              0x00007fff850a057d -[NSScrollView tile] + 1605
    8   AppKit                              0x00007fff8509fe9d -[NSScrollView _tileWithoutRecursing] + 51
    9   AppKit                              0x00007fff8509df0b -[NSScrollView reflectScrolledClipView:] + 1059
    10  AppKit                              0x00007fff850a98bc -[NSClipView _reflectDocumentViewFrameChange] + 172
    11  AppKit                              0x00007fff850732b1 -[NSView _postFrameChangeNotification] + 206
    12  AppKit                              0x00007fff8507b0fb -[NSView setFrameSize:] + 2059
    13  AppKit                              0x00007fff851ce0c4 -[NSTextView(NSPrivate) _setFrameSize:forceScroll:] + 735
    14  AppKit                              0x00007fff85148ed2 -[NSTextView setConstrainedFrameSize:] + 642
    15  UIFoundation                        0x00007fff84123c94 -[NSLayoutManager(NSPrivate) _resizeTextViewForTextContainer:] + 1058
    16  UIFoundation                        0x00007fff8412372e -[NSLayoutManager(NSPrivate) _recalculateUsageForTextContainerAtIndex:] + 2745
    17  UIFoundation                        0x00007fff84075769 -[NSLayoutManager textStorage:edited:range:changeInLength:invalidatedRange:] + 753
    18  UIFoundation                        0x00007fff84097481 -[NSTextStorage _notifyEdited:range:changeInLength:invalidatedRange:] + 152
    19  UIFoundation                        0x00007fff84096f83 -[NSTextStorage processEditing] + 198
    20  UIFoundation                        0x00007fff84096e88 -[NSTextStorage edited:range:changeInLength:] + 312
    21  UIFoundation                        0x00007fff84098593 -[NSConcreteTextStorage replaceCharactersInRange:withString:] + 138
    22  AppKit                              0x00007fff852a6c6f -[NSTextView(NSPrivate) _userReplaceRange:withString:] + 213
    23  AppKit                              0x00007fff852a696b _NSDoUserReplaceForCharRange + 468
    24  AppKit                              0x00007fff852a6786 _NSDoUserDeleteForCharRange + 38
    25  AppKit                              0x00007fff852a5e19 -[NSTextView(NSKeyBindingCommands) deleteBackward:] + 545
    26  AppKit                              0x00007fff85258686 -[NSTextView doCommandBySelector:] + 195
    27  AppKit                              0x00007fff858731f1 -[NSTextInputContext(NSInputContext_WithCompletion) doCommandBySelector:completionHandler:] + 118
    28  AppKit                              0x00007fff8522dca7 -[NSKeyBindingManager(NSKeyBindingManager_MultiClients) interpretEventAsCommand:forClient:] + 1899
    29  AppKit                              0x00007fff85871b82 __61-[NSTextInputContext _handleEvent:options:completionHandler:]_block_invoke972 + 335
    30  AppKit                              0x00007fff8587365f -[NSTextInputContext(NSInputContext_WithCompletion) hasMarkedTextWithCompletionHandler:] + 76
    31  AppKit                              0x00007fff858719a3 __61-[NSTextInputContext _handleEvent:options:completionHandler:]_block_invoke_3 + 95
    32  AppKit                              0x00007fff85870ce8 -[NSTextInputContext tryHandleEvent_HasMarkedText_withDispatchCondition:dispatchWork:continuation:] + 101
    33  AppKit                              0x00007fff85871914 __61-[NSTextInputContext _handleEvent:options:completionHandler:]_block_invoke960 + 321
    34  HIToolbox                           0x00007fff8d350c4f __TSMProcessRawKeyEventWithOptionsAndCompletionHandler_block_invoke_5 + 70
    35  HIToolbox                           0x00007fff8d2a8695 ___ZL23DispatchEventToHandlersP14EventTargetRecP14OpaqueEventRefP14HandlerCallRec_block_invoke + 108
    36  AppKit                              0x00007fff8586a676 __55-[NSTextInputContext handleTSMEvent:completionHandler:]_block_invoke174 + 2387
    37  AppKit                              0x00007fff8587365f -[NSTextInputContext(NSInputContext_WithCompletion) hasMarkedTextWithCompletionHandler:] + 76
    38  AppKit                              0x00007fff85869c90 __55-[NSTextInputContext handleTSMEvent:completionHandler:]_block_invoke_2 + 95
    39  AppKit                              0x00007fff858679a8 -[NSTextInputContext tryHandleTSMEvent_HasMarkedText_withDispatchCondition:dispatchWork:continuation:] + 101
    40  AppKit                              0x00007fff85869905 -[NSTextInputContext handleTSMEvent:completionHandler:] + 3122
    41  AppKit                              0x00007fff8524ceee _NSTSMEventHandler + 324
    42  HIToolbox                           0x00007fff8d13798c _ZL23DispatchEventToHandlersP14EventTargetRecP14OpaqueEventRefP14HandlerCallRec + 1260
    43  HIToolbox                           0x00007fff8d136dce _ZL30SendEventToEventTargetInternalP14OpaqueEventRefP20OpaqueEventTargetRefP14HandlerCallRec + 386
    44  HIToolbox                           0x00007fff8d136c42 SendEventToEventTargetWithOptions + 43
    45  HIToolbox                           0x00007fff8d349f4c SendTSMEvent_WithCompletionHandler + 417
    46  HIToolbox                           0x00007fff8d34a44c __SendUnicodeTextAEToUnicodeDoc_WithCompletionHandler_block_invoke + 400
    47  HIToolbox                           0x00007fff8d34a706 __SendFilterTextEvent_WithCompletionHandler_block_invoke + 189
    48  HIToolbox                           0x00007fff8d349fa0 SendTSMEvent_WithCompletionHandler + 501
    49  HIToolbox                           0x00007fff8d34a28f SendFilterTextEvent_WithCompletionHandler + 236
    50  HIToolbox                           0x00007fff8d347601 SendUnicodeTextAEToUnicodeDoc_WithCompletionHandler + 295
    51  HIToolbox                           0x00007fff8d34bf09 __utDeliverTSMEvent_WithCompletionHandler_block_invoke_2 + 296
    52  HIToolbox                           0x00007fff8d34bdd8 __utDeliverTSMEvent_WithCompletionHandler_block_invoke + 437
    53  HIToolbox                           0x00007fff8d34707d TSMKeyEvent_WithCompletionHandler + 701
    54  HIToolbox                           0x00007fff8d350bd0 __TSMProcessRawKeyEventWithOptionsAndCompletionHandler_block_invoke_4 + 251
    55  HIToolbox                           0x00007fff8d350ac6 __TSMProcessRawKeyEventWithOptionsAndCompletionHandler_block_invoke_3 + 330
    56  HIToolbox                           0x00007fff8d350902 __TSMProcessRawKeyEventWithOptionsAndCompletionHandler_block_invoke_2 + 259
    57  HIToolbox                           0x00007fff8d350785 __TSMProcessRawKeyEventWithOptionsAndCompletionHandler_block_invoke + 251
    58  HIToolbox                           0x00007fff8d35058f TSMProcessRawKeyEventWithOptionsAndCompletionHandler + 3068
    59  AppKit                              0x00007fff85871726 __61-[NSTextInputContext _handleEvent:options:completionHandler:]_block_invoke949 + 131
    60  AppKit                              0x00007fff85870c12 -[NSTextInputContext tryTSMProcessRawKeyEvent:dispatchCondition:setupForDispatch:furtherCondition:dispatchWork:continuation:] + 127
    61  AppKit                              0x00007fff85871245 -[NSTextInputContext _handleEvent:options:completionHandler:] + 1266
    62  AppKit                              0x00007fff8524c71e -[NSTextInputContext handleEvent:] + 109
    63  AppKit                              0x00007fff8522c374 -[NSView interpretKeyEvents:] + 207
    64  AppKit                              0x00007fff8524c597 -[NSTextView keyDown:] + 695
    65  AppKit                              0x00007fff85773fdb -[NSWindow _reallySendEvent:] + 6004
    66  AppKit                              0x00007fff851fc16e -[NSWindow sendEvent:] + 446
    67  AppKit                              0x00007fff851ae3d1 -[NSApplication sendEvent:] + 4055
    68  AppKit                              0x00007fff8503a608 -[NSApplication run] + 711
    69  AppKit                              0x00007fff85025a14 NSApplicationMain + 1832
    70  MGSFragariaView                     0x0000000100005c82 main + 34
    71  libdyld.dylib                       0x00007fff887825c9 start + 1
)
2015-02-28 23:18:34.240 MGSFragariaView[85233:52385397] *** -[__NSArrayM objectAtIndex:]: index 5 beyond bounds [0 .. 0]
2015-02-28 23:18:34.241 MGSFragariaView[85233:52385397] (
    0   CoreFoundation                      0x00007fff8c75066c __exceptionPreprocess + 172
    1   libobjc.A.dylib                     0x00007fff8a8a376e objc_exception_throw + 43
    2   CoreFoundation                      0x00007fff8c61adf4 -[__NSArrayM objectAtIndex:] + 260
    3   MGSFragaria                         0x0000000100040305 -[MGSLineNumberView wholeLineRectForLine:] + 789
    4   MGSFragaria                         0x0000000100041371 -[MGSLineNumberView decorationRectOfLine:] + 353
    5   MGSFragaria                         0x000000010003eaf1 -[MGSLineNumberView decorationColumnWidth] + 513
    6   MGSFragaria                         0x000000010003e811 -[MGSLineNumberView requiredThickness] + 593
    7   MGSFragaria                         0x000000010003ed61 -[MGSLineNumberView viewWillDraw] + 161
    8   AppKit                              0x00007fff85175aa1 -[NSView(NSInternal) _sendViewWillDrawAndRecurse:] + 535
    9   AppKit                              0x00007fff85175641 -[NSView(NSLayerKitGlue) _layoutSublayersOfLayer:] + 142
    10  QuartzCore                          0x00007fff85bc2050 -[CALayer layoutSublayers] + 219
    11  AppKit                              0x00007fff8517559d _NSBackingLayerLayoutSublayers + 158
    12  QuartzCore                          0x00007fff85bc1c34 _ZN2CA5Layer16layout_if_neededEPNS_11TransactionE + 366
    13  QuartzCore                          0x00007fff85bc1ab2 _ZN2CA5Layer28layout_and_display_if_neededEPNS_11TransactionE + 24
    14  QuartzCore                          0x00007fff85bc124e _ZN2CA7Context18commit_transactionEPNS_11TransactionE + 242
    15  QuartzCore                          0x00007fff85bc0ea4 _ZN2CA11Transaction6commitEv + 390
    16  QuartzCore                          0x00007fff85bd1cad _ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv + 71
    17  CoreFoundation                      0x00007fff8c66dda7 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23
    18  CoreFoundation                      0x00007fff8c66dd00 __CFRunLoopDoObservers + 368
    19  CoreFoundation                      0x00007fff8c65f878 CFRunLoopRunSpecific + 328
    20  HIToolbox                           0x00007fff8d15daef RunCurrentEventLoopInMode + 235
    21  HIToolbox                           0x00007fff8d15d76e ReceiveNextEventCommon + 179
    22  HIToolbox                           0x00007fff8d15d6ab _BlockUntilNextEventMatchingListInModeWithFilter + 71
    23  AppKit                              0x00007fff85046f81 _DPSNextEvent + 964
    24  AppKit                              0x00007fff85046730 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 194
    25  AppKit                              0x00007fff8503a593 -[NSApplication run] + 594
    26  AppKit                              0x00007fff85025a14 NSApplicationMain + 1832
    27  MGSFragariaView                     0x0000000100005c82 main + 34
    28  libdyld.dylib                       0x00007fff887825c9 start + 1
)

Hmmm... actually it seems to happen if I select more than one line and try to delete it.

MGSFragariaView refactored to eliminate MGSFragaria dependency

You mentioned this before; I simply wanted to capture it as an issue.

MGSFragariaPreferences role?

MGSFragariaPreferences is currently instituted as a singleton, but the only use of it in the code is in the Simple demo application, where it's only used to eventually resolve back to the shared NSUserDefaultsController.

It also provides ready-made instances of the two view controllers, but the demo app is instantiating its own controllers, so these aren't really necessary, either, unless we want them to remain for other applications to use.

I'll keep it all in and add lazy instantiation for the controllers, but I'd like to rip this out entirely, as I don't see a need for it.

Make it easier to add/remove MGSFragaria from a preference group

With the current API you have to get the managedInstances property, make a mutable copy, add/remove the item you want, and then set managedInstances again.

Apart from taking a lot of code, when the managedInstances property is set, the preferences manager loops thru all the registered properties for all the registered views and re-binds them all, which I guess is not very fast. An add/remove API in the defaults controller would allow binding/unbinding only when's needed.

Error display properties should be separated

Just food for thought. Perhaps we should should have separate properties in the API for separately turning on and off error displays:

• in the gutter
• highlighting in the document
• individual error highlighting

Maybe a master switch to turn all error displays on/off.

code folding support

How difficult it is to add code folding support in fragaria?

support for different fonts (family, trait & size) in highlighter

I didn't found how to set up differents fonts in the highlighter. Is it supported and if not, do you have any direction for the implementation?

Additional syntax properties

Some text editors — in addition to coloring syntax elements — can specify basic styles such as bold, oblique or italic, and underlined. Any thoughts?

MGSSyntaxController get file extension based on a given name.

How to get a file extension when user selected language combobox (MGSSyntaxController) ?

Thanks

Syntax Highlighter multiline blocks not handled correctly

Suppose you have a comment taller than the scroll view's content frame. Scroll to the top of the comment (a part of the comment is now invisible) and delete the comment's opening tag. Scrolling down will reveal that the rest of the comment is still colored.

This bug affects all multiline items. It is mitigated by the fact that in textDidChange: we call invalidateVisibleRange instead of recolourExposedRange: without this mitigation only the edited line would be correctly colored.

Tri-state breakpoints; other breakpoint images/colors

Raising this as a proposed issue/feature request.

Right now the breakpoints are dead-simple, and that's a good thing. If we want to make it more complicated, though, there are opportunities for multiple colors and/or image sources (mentioned in another issue, but thought it deserved to be top-level).

There is also the possibility of tri-state (or multi-state) breakpoints, e.g., breakpoint enabled, breakpoint disabled, and no breakpoint, a la Xcode.

For discussion I would propose that it's silly for a view to manage all of this, and would propose that the application is responsible. This would leave the breakpoint as a decoration only (with click feedback), but would have to provide some mechanism to provide different breakpoint images.

Centralize error buttons handling

Make a controller class which holds the syntaxErrors array and manages line highlighting and creation of error buttons.

Add configuration for brace matching.

It'd be useful to be able to configure the brace matching, including which characters to count as braces, and to be able to disable the beep on a mismatch.

Does it support JSON highlighting?

I was not able to see JSON in the list of supported languages in the README

Custom Auto Complete Words

How is possible to add or modify auto complete words? I want to implement this function during typing!

Thanks

Fragaria with Storyboards

I try to integrate Fragaria in a Swift 3.0 project. First I built Fragaria as a Framework. This I added to my project. I work with storyboards.

In Swift-Example a IBOutlet generated by the types MSGFragariaView. I unfortunately do not get this in my project.

Have I made something wrong in the creation or incorporating as a framework?

I hope you can help me.

Thanks in advance.

Syntax Highlighter breaks if multiple blocks have the same color

The syntax highlighter reads in various places on the existing coloring to:

• check if a string parsing operation was suspended (range too short)
• check if a string is inside a comment
• possibly other places?

Fragaria instances sharing the same text storage also share the same text color

Currently, the Fragaria which sets its text color last wins.

Support real split views

The only change really needed to support real split view is to move change tracking from SMLTextView to SMLSyntaxColouring, reimplemented as observing the text storage for changes.

Bindings / KVO / KVC Discussion

@shysaur, I've been digging into a several possible solutions for observing one or more instances of Fragaria and tying it/them to the user defaults system. I've also learned a lot about the "magic" behind bindings in this journey. I would appreciate your feedback on direction (it has nothing to do with userDefaults at all, but bindings and KVO/KVC).

Summary:

• Direction (1): leave everything else alone and do all KVO/KVC externally. Easiest.
• Direction (2): make MGSFragaria bindings-compatible. Ugly, most difficult due to the many levels of responsible objects.
• Direction (3): Do KVO/KVC in MGSFragariaView and make it bindings compatible. Irritating to do, but probably the most elegant from the user perspective.

Discussion:

Right now MGSFragaria and its properties are observable and settable via KVO/KVC, either via MGSFragaria directly or via its exposed components. From the scope of a new "MGSObserver" type of class, it's relatively trivial to observe the desired properties via KVO and set the desired properties via KVC.

Therefore direction (1) would be to handle all of this externally in this hypothetical optional class.

Currently MGSFragaria and its component classes inherit the default behavior for bind:toObject:withKeyPath:options from NSObject, which results in a one-way binding, i.e., MGSFragaria can observe an arbitrary model, but cannot provide updates to that model.

Obviously two-way binding is a nice feature to have (a "want"), but not a necessity to have (not a "need"). Additionally adding it to the base Fragaria class would require (I think):

• adding the code to every top level component (the SMLTextView, etc.) so that they ALL implement the return binding.
• Or removing the dynamic properties and making every pertinent property part of base MGSFragaria again.

(Essentially the property setters have to all be able to check -[NSObject infoForBinding:] and update the model via KVC).

Therefore direction (2) would be to start re-implementing all of this so that MGSFragaria can be bindings compatible in both directions).

I rather abhor Direction (2) because it undoes a lot of leanness that you've introduced to MGSFragaria, but it is a solution.

Direction (3) might be making MGSFragariaView fully bindings compatible. It can handle all of the manual KVO/KVC in Direction (1), and provide abstracted properties for everything relevant to MGSFragaria, without making MGSFragaria heavy again.

I'd abandoned MGSFragariaView and there's a @todo suggesting no need to abstract MGSFragaria's properties, but if I do that then the class is only a minor convenience, especially after having removed embedInView:. If I add the properties back and make them bindings compatible, it suddenly becomes much more useful to other developers.

However the new hypothetical "MGSObserver" type of class would then only work with MGSFragariaView instead of MGSFragaria (which may be a good thing, as MGSFragaria still has the old defaults system to use).

I can make my proposed multiple-Fragaria-instances user defaults proposal work with any of the above. Any thoughts, or other ideas that I've not mentioned?

Some behavior too dependent on NSUserDefaults

A lot of Smultron's and Fragaria's settings and behaviors are linked directly to NSUserDefaults, meaning that multiple instances of Fragaria can't have independent settings, or the custom setting is undone whenever the default changes.

This is something I plan to tackle, but I'm not sure if it's on your radar or not.