shysaur / fragaria Goto Github PK
View Code? Open in Web Editor NEWThis project forked from mz2/fragaria
Cocoa syntax highlighting text view
This project forked from mz2/fragaria
Cocoa syntax highlighting text view
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?
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.
Are you willing to sacrifice the in-body error buttons in favor of this:
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:
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.
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).
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:
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.
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.
The hideWarning property of SMLSyntaxError is not always observed when creating highlights and buttons.
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.
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).
In the current MGSFragariaViewModern example, the Attributes color well is an example of this misbehavior.
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.
Originally, docSpecs were used to persist document state. But there are far less painful alternatives.
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.
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.
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 :)
This makes easier to have a single preferences controller for every MGSFragariaView in an application.
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.
Perhaps we should add another property to allow for customizable leading in the view.
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.
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.
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
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.
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.
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.
You mentioned this before; I simply wanted to capture it as an issue.
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.
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.
Just food for thought. Perhaps we should should have separate properties in the API for separately turning on and off error displays:
Maybe a master switch to turn all error displays on/off.
How difficult it is to add code folding support in fragaria?
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?
Some text editors โ in addition to coloring syntax elements โ can specify basic styles such as bold, oblique or italic, and underlined. Any thoughts?
How to get a file extension when user selected language combobox (MGSSyntaxController) ?
Thanks
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.
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.
Make a controller class which holds the syntaxErrors array and manages line highlighting and creation of error buttons.
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.
I was not able to see JSON in the list of supported languages in the README
How is possible to add or modify auto complete words? I want to implement this function during typing!
Thanks
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.
The syntax highlighter reads in various places on the existing coloring to:
Currently, the Fragaria which sets its text color last wins.
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.
@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:
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):
(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?
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.