Back references and theme with font, in pure Swift and SPM support #6
Conversation
… feature-back-refs # Conflicts: # SyntaxKit/Pattern.swift
| internal struct Result: Equatable { | ||
|
|
||
| // MARK: - Properties | ||
|
|
||
| let patternIdentifier: String | ||
| var range: NSRange | ||
| let result: NSTextCheckingResult? |
There was a problem hiding this comment.
Maybe rename this so that it is clear that this is the result of the match from a previous regex.
| private var fontName: String = Theme.defaultFontName | ||
| private var fontSize: CGFloat = Theme.defaultFontSize | ||
| private var fontCallback: FontCallback? |
There was a problem hiding this comment.
The theme has nothing to do with font size or font name which should be selected by the application based on other criteria. So the FontCallback should return a font for a given FontStyle which it then uses. Alternatively, instead of a callback a struct with one font for each style could be passed in.
There was a problem hiding this comment.
Yes, thank you for your suggestion. But I am not sure if TextMate theme will control font family and font size: https://github.com/textmate/textmate/blob/e4e54440b509557b79b2bd6f7b54bca279a88358/Frameworks/theme/src/theme.cc#L59
There was a problem hiding this comment.
Even if it is supported by textmate, I think these properties should simply be ignored. The text editor should always control typeface and font size (especially since installed fonts are something that differ from machine to machine, worse the same font might be named differently). I don't know any text editor which only lets the theme control these two properties (either it is fixed, or the user can choose).
| @@ -278,9 +281,9 @@ open class Parser { | |||
| if range.location == NSNotFound { | |||
| continue | |||
| } | |||
|
|
|||
|
|
||
| import Foundation | ||
|
|
||
| internal extension String { |
There was a problem hiding this comment.
Why are we using CStrings here everywhere?
There was a problem hiding this comment.
Maybe it's faster? I have no better idea because I copied these codes from my Objective-C project.
There was a problem hiding this comment.
In soffes#18, you said:
\G is not supported (for performance reasons the parser does not guarantee to match the end of a pattern right after begin, and even if it would, \G behaves wierdly with NSRegularExpression). This might be fixable.
To fix this, I am making my progress to import Oniguruma.
There was a problem hiding this comment.
CStrings should not be used, unless you are interoperating with C.
There was a problem hiding this comment.
About the other problem, I would maybe do a test with NSRegularExpression vs Oniguruma to see where they behave differently. Obviously it would be better to keep using NSRegularExpression.
| @@ -157,7 +175,7 @@ open class AttributedParsingOperation: Operation { | |||
| /// | |||
| /// - returns: A range in newString that can be safely re-parsed. Or nil if | |||
| /// everything has to be reparsed. | |||
| class func outdatedRange(in newString: NSString, forChange diff: Diff, updatingPreviousResult previous: inout ScopedString) -> NSRange? { | |||
| class func outdatedRange(in newString: NSString, forChange diff: Diff, updatingPreviousResult previous: inout ScopedString) -> NSRange { | |||
There was a problem hiding this comment.
The outdated range calculated here sometimes seems incorrent...
Especially near a new line separator. Any ideas?
Fix some caveats mentioned here: soffes#18