coteditor
Syntax Highlighting: Lua
Quotes
Strings are introduced in section 2.1 of the Reference Manual. Strings can be defined using single quotes, double quotes, or double square brackets.
> = "hello"
hello
> = 'hello'
hello
> = [[hello]]
hello
Why so many ways to make a string? It allows you to enclose one type of quotes in the other. e.g.,
> = 'hello "Lua user"'
hello "Lua user"
> = "Its [[content]] hasn't got a substring."
Its [[content]] hasn't got a substring.
> = [[Let's have more "strings" please.]]
Let's have more "strings" please.
Double bracketed strings also have a few other special properties, discussed below.
Escape sequences
Lua can also handle C-like escape sequences. There are more details in the Reference Manual, Section 2.1.
> = "hello \"Lua user\""
hello "Lua user"
> = 'hello\nNew line\tTab'
hello
New line Tab
Escape sequences are not recognized when using double brackets, so:
> = [[hello\nNew line\tTab]]
hello\nNew line\tTab
Multiline quotes
Double square brackets can be used to enclose literal strings which traverse several lines. e.g.,
> = [[Multiple lines of text
>> can be enclosed in double square
>> brackets.]]
Multiple lines of text
can be enclosed in double square
brackets.
Nesting quotes
Double square brackets allow nesting, but they require one or more = inserted in the outer-most brackets to distinguish them. It doesn't matter how many = are inserted, as long as the number is the same in the beginning and ending brackets.
> = [[one [[two]] one]] -- bad
stdin:1: nesting of [[...]] is deprecated near '['
> = [=[one [[two]] one]=] -- ok
one [[two]] one
> = [===[one [[two]] one]===] -- ok too
one [[two]] one
> = [=[one [ [==[ one]=] -- ok. nothing special about the inner content.
one [ [==[ one
To support this, syntax highlighting engine should support back reference. Example:
strings:
- beginString: "[(=*)["
endString: "]$1]"
regularExpression: true
commentDelimiters:
- beginDelimiter: "--[(=*)["
endDelimiter: "]$1]"
inlineDelimiter: "--"
regularExpression: true
It is important because multi-line string/comment are widely used in this language.
Here is my implementation of syntax highlighting, using TextMate's syntax rules. I think it's accurate but too complex, just in case: https://github.com/Lessica/SyntaxKit
Thank you for the feedback. I've just quick updated the style halfway. As you pointed out, to fulfill the request perfectly, the syntax parse engine needs to introduce a new rule that requires consideration. Let me have a time.
BTW, why storyboard, not xib for simple views?
It's just my preference. But actually, using storyboards instead of xibs has advantages in AppKit, such as managing view controller hierarchy.
Aha, sorry. I realized that your suggested style change for [[ ]] string delimiter highlight with regex doesn't work in some cases. I'll try another way.
@1024jp Problem still exists. You have to implement back references in multi-line tokenizers.
"abc123" -- OK
[[ abc123 ]] -- OK
[==[ abc123 ]==] -- OK
[[
abc123
]] -- OK
[==[
123
]==] -- FAILED
--[==[
123
]==] -- FAILED
Screenshots
@Lessica Yes, right. I have not done all yet regarding this issue. Therefore, I have not close this ticket yet. In order to solve all of these, I need to modify not only the syntax style definition but also the core parser for syntax highlighting. Let me have time. Regrettably, it potentially requires a large change that I even don't have a perfect solution yet.