2020-03-14 00:07:44 +02:00
|
|
|
/*
|
|
|
|
* Copyright (c) 2020, the SerenityOS developers.
|
|
|
|
* All rights reserved.
|
|
|
|
*
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
* modification, are permitted provided that the following conditions are met:
|
|
|
|
*
|
|
|
|
* 1. Redistributions of source code must retain the above copyright notice, this
|
|
|
|
* list of conditions and the following disclaimer.
|
|
|
|
*
|
|
|
|
* 2. Redistributions in binary form must reproduce the above copyright notice,
|
|
|
|
* this list of conditions and the following disclaimer in the documentation
|
|
|
|
* and/or other materials provided with the distribution.
|
|
|
|
*
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
|
|
|
|
* AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
|
|
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
|
|
|
|
* DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
|
|
|
|
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
|
|
|
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
|
|
|
|
* SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
|
|
|
|
* CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
|
|
|
|
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
|
|
|
|
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
*/
|
|
|
|
|
2021-01-16 15:51:56 +01:00
|
|
|
#include <AK/Debug.h>
|
2020-03-13 00:52:03 +02:00
|
|
|
#include <LibGUI/TextEditor.h>
|
|
|
|
#include <LibGfx/Font.h>
|
2020-03-16 01:05:06 +02:00
|
|
|
#include <LibGfx/Palette.h>
|
2020-03-13 00:52:03 +02:00
|
|
|
#include <LibJS/Lexer.h>
|
2021-02-07 16:56:02 +01:00
|
|
|
#include <LibJS/SyntaxHighlighter.h>
|
2020-03-13 00:52:03 +02:00
|
|
|
#include <LibJS/Token.h>
|
|
|
|
|
2021-02-07 16:56:02 +01:00
|
|
|
namespace JS {
|
2020-03-13 00:52:03 +02:00
|
|
|
|
2021-02-07 16:56:02 +01:00
|
|
|
static Syntax::TextStyle style_for_token_type(const Gfx::Palette& palette, JS::TokenType type)
|
2020-03-13 00:52:03 +02:00
|
|
|
{
|
LibJS: Unify syntax highlighting
So far we have three different syntax highlighters for LibJS:
- js's Line::Editor stylization
- JS::MarkupGenerator
- GUI::JSSyntaxHighlighter
This not only caused repetition of most token types in each highlighter
but also a lot of inconsistency regarding the styling of certain tokens:
- JSSyntaxHighlighter was considering TokenType::Period to be an
operator whereas MarkupGenerator categorized it as punctuation.
- MarkupGenerator was considering TokenType::{Break,Case,Continue,
Default,Switch,With} control keywords whereas JSSyntaxHighlighter just
disregarded them
- MarkupGenerator considered some future reserved keywords invalid and
others not. JSSyntaxHighlighter and js disregarded most
Adding a new token type meant adding it to ENUMERATE_JS_TOKENS as well
as each individual highlighter's switch/case construct.
I added a TokenCategory enum, and each TokenType is now associated to a
certain category, which the syntax highlighters then can use for styling
rather than operating on the token type directly. This also makes
changing a token's category everywhere easier, should we need to do that
(e.g. I decided to make TokenType::{Period,QuestionMarkPeriod}
TokenCategory::Operator for now, but we might want to change them to
Punctuation.
2020-10-04 22:28:59 +01:00
|
|
|
switch (JS::Token::category(type)) {
|
|
|
|
case JS::TokenCategory::Invalid:
|
2020-03-16 01:05:06 +02:00
|
|
|
return { palette.syntax_comment() };
|
LibJS: Unify syntax highlighting
So far we have three different syntax highlighters for LibJS:
- js's Line::Editor stylization
- JS::MarkupGenerator
- GUI::JSSyntaxHighlighter
This not only caused repetition of most token types in each highlighter
but also a lot of inconsistency regarding the styling of certain tokens:
- JSSyntaxHighlighter was considering TokenType::Period to be an
operator whereas MarkupGenerator categorized it as punctuation.
- MarkupGenerator was considering TokenType::{Break,Case,Continue,
Default,Switch,With} control keywords whereas JSSyntaxHighlighter just
disregarded them
- MarkupGenerator considered some future reserved keywords invalid and
others not. JSSyntaxHighlighter and js disregarded most
Adding a new token type meant adding it to ENUMERATE_JS_TOKENS as well
as each individual highlighter's switch/case construct.
I added a TokenCategory enum, and each TokenType is now associated to a
certain category, which the syntax highlighters then can use for styling
rather than operating on the token type directly. This also makes
changing a token's category everywhere easier, should we need to do that
(e.g. I decided to make TokenType::{Period,QuestionMarkPeriod}
TokenCategory::Operator for now, but we might want to change them to
Punctuation.
2020-10-04 22:28:59 +01:00
|
|
|
case JS::TokenCategory::Number:
|
2020-03-16 01:05:06 +02:00
|
|
|
return { palette.syntax_number() };
|
LibJS: Unify syntax highlighting
So far we have three different syntax highlighters for LibJS:
- js's Line::Editor stylization
- JS::MarkupGenerator
- GUI::JSSyntaxHighlighter
This not only caused repetition of most token types in each highlighter
but also a lot of inconsistency regarding the styling of certain tokens:
- JSSyntaxHighlighter was considering TokenType::Period to be an
operator whereas MarkupGenerator categorized it as punctuation.
- MarkupGenerator was considering TokenType::{Break,Case,Continue,
Default,Switch,With} control keywords whereas JSSyntaxHighlighter just
disregarded them
- MarkupGenerator considered some future reserved keywords invalid and
others not. JSSyntaxHighlighter and js disregarded most
Adding a new token type meant adding it to ENUMERATE_JS_TOKENS as well
as each individual highlighter's switch/case construct.
I added a TokenCategory enum, and each TokenType is now associated to a
certain category, which the syntax highlighters then can use for styling
rather than operating on the token type directly. This also makes
changing a token's category everywhere easier, should we need to do that
(e.g. I decided to make TokenType::{Period,QuestionMarkPeriod}
TokenCategory::Operator for now, but we might want to change them to
Punctuation.
2020-10-04 22:28:59 +01:00
|
|
|
case JS::TokenCategory::String:
|
2020-03-16 01:05:06 +02:00
|
|
|
return { palette.syntax_string() };
|
LibJS: Unify syntax highlighting
So far we have three different syntax highlighters for LibJS:
- js's Line::Editor stylization
- JS::MarkupGenerator
- GUI::JSSyntaxHighlighter
This not only caused repetition of most token types in each highlighter
but also a lot of inconsistency regarding the styling of certain tokens:
- JSSyntaxHighlighter was considering TokenType::Period to be an
operator whereas MarkupGenerator categorized it as punctuation.
- MarkupGenerator was considering TokenType::{Break,Case,Continue,
Default,Switch,With} control keywords whereas JSSyntaxHighlighter just
disregarded them
- MarkupGenerator considered some future reserved keywords invalid and
others not. JSSyntaxHighlighter and js disregarded most
Adding a new token type meant adding it to ENUMERATE_JS_TOKENS as well
as each individual highlighter's switch/case construct.
I added a TokenCategory enum, and each TokenType is now associated to a
certain category, which the syntax highlighters then can use for styling
rather than operating on the token type directly. This also makes
changing a token's category everywhere easier, should we need to do that
(e.g. I decided to make TokenType::{Period,QuestionMarkPeriod}
TokenCategory::Operator for now, but we might want to change them to
Punctuation.
2020-10-04 22:28:59 +01:00
|
|
|
case JS::TokenCategory::Punctuation:
|
2020-03-16 01:05:06 +02:00
|
|
|
return { palette.syntax_punctuation() };
|
LibJS: Unify syntax highlighting
So far we have three different syntax highlighters for LibJS:
- js's Line::Editor stylization
- JS::MarkupGenerator
- GUI::JSSyntaxHighlighter
This not only caused repetition of most token types in each highlighter
but also a lot of inconsistency regarding the styling of certain tokens:
- JSSyntaxHighlighter was considering TokenType::Period to be an
operator whereas MarkupGenerator categorized it as punctuation.
- MarkupGenerator was considering TokenType::{Break,Case,Continue,
Default,Switch,With} control keywords whereas JSSyntaxHighlighter just
disregarded them
- MarkupGenerator considered some future reserved keywords invalid and
others not. JSSyntaxHighlighter and js disregarded most
Adding a new token type meant adding it to ENUMERATE_JS_TOKENS as well
as each individual highlighter's switch/case construct.
I added a TokenCategory enum, and each TokenType is now associated to a
certain category, which the syntax highlighters then can use for styling
rather than operating on the token type directly. This also makes
changing a token's category everywhere easier, should we need to do that
(e.g. I decided to make TokenType::{Period,QuestionMarkPeriod}
TokenCategory::Operator for now, but we might want to change them to
Punctuation.
2020-10-04 22:28:59 +01:00
|
|
|
case JS::TokenCategory::Operator:
|
2020-03-16 01:05:06 +02:00
|
|
|
return { palette.syntax_operator() };
|
LibJS: Unify syntax highlighting
So far we have three different syntax highlighters for LibJS:
- js's Line::Editor stylization
- JS::MarkupGenerator
- GUI::JSSyntaxHighlighter
This not only caused repetition of most token types in each highlighter
but also a lot of inconsistency regarding the styling of certain tokens:
- JSSyntaxHighlighter was considering TokenType::Period to be an
operator whereas MarkupGenerator categorized it as punctuation.
- MarkupGenerator was considering TokenType::{Break,Case,Continue,
Default,Switch,With} control keywords whereas JSSyntaxHighlighter just
disregarded them
- MarkupGenerator considered some future reserved keywords invalid and
others not. JSSyntaxHighlighter and js disregarded most
Adding a new token type meant adding it to ENUMERATE_JS_TOKENS as well
as each individual highlighter's switch/case construct.
I added a TokenCategory enum, and each TokenType is now associated to a
certain category, which the syntax highlighters then can use for styling
rather than operating on the token type directly. This also makes
changing a token's category everywhere easier, should we need to do that
(e.g. I decided to make TokenType::{Period,QuestionMarkPeriod}
TokenCategory::Operator for now, but we might want to change them to
Punctuation.
2020-10-04 22:28:59 +01:00
|
|
|
case JS::TokenCategory::Keyword:
|
2020-12-28 15:51:43 +01:00
|
|
|
return { palette.syntax_keyword(), true };
|
LibJS: Unify syntax highlighting
So far we have three different syntax highlighters for LibJS:
- js's Line::Editor stylization
- JS::MarkupGenerator
- GUI::JSSyntaxHighlighter
This not only caused repetition of most token types in each highlighter
but also a lot of inconsistency regarding the styling of certain tokens:
- JSSyntaxHighlighter was considering TokenType::Period to be an
operator whereas MarkupGenerator categorized it as punctuation.
- MarkupGenerator was considering TokenType::{Break,Case,Continue,
Default,Switch,With} control keywords whereas JSSyntaxHighlighter just
disregarded them
- MarkupGenerator considered some future reserved keywords invalid and
others not. JSSyntaxHighlighter and js disregarded most
Adding a new token type meant adding it to ENUMERATE_JS_TOKENS as well
as each individual highlighter's switch/case construct.
I added a TokenCategory enum, and each TokenType is now associated to a
certain category, which the syntax highlighters then can use for styling
rather than operating on the token type directly. This also makes
changing a token's category everywhere easier, should we need to do that
(e.g. I decided to make TokenType::{Period,QuestionMarkPeriod}
TokenCategory::Operator for now, but we might want to change them to
Punctuation.
2020-10-04 22:28:59 +01:00
|
|
|
case JS::TokenCategory::ControlKeyword:
|
2020-12-28 15:51:43 +01:00
|
|
|
return { palette.syntax_control_keyword(), true };
|
LibJS: Unify syntax highlighting
So far we have three different syntax highlighters for LibJS:
- js's Line::Editor stylization
- JS::MarkupGenerator
- GUI::JSSyntaxHighlighter
This not only caused repetition of most token types in each highlighter
but also a lot of inconsistency regarding the styling of certain tokens:
- JSSyntaxHighlighter was considering TokenType::Period to be an
operator whereas MarkupGenerator categorized it as punctuation.
- MarkupGenerator was considering TokenType::{Break,Case,Continue,
Default,Switch,With} control keywords whereas JSSyntaxHighlighter just
disregarded them
- MarkupGenerator considered some future reserved keywords invalid and
others not. JSSyntaxHighlighter and js disregarded most
Adding a new token type meant adding it to ENUMERATE_JS_TOKENS as well
as each individual highlighter's switch/case construct.
I added a TokenCategory enum, and each TokenType is now associated to a
certain category, which the syntax highlighters then can use for styling
rather than operating on the token type directly. This also makes
changing a token's category everywhere easier, should we need to do that
(e.g. I decided to make TokenType::{Period,QuestionMarkPeriod}
TokenCategory::Operator for now, but we might want to change them to
Punctuation.
2020-10-04 22:28:59 +01:00
|
|
|
case JS::TokenCategory::Identifier:
|
2020-03-16 01:05:06 +02:00
|
|
|
return { palette.syntax_identifier() };
|
2020-03-13 00:52:03 +02:00
|
|
|
default:
|
2020-03-16 01:05:06 +02:00
|
|
|
return { palette.base_text() };
|
2020-03-13 00:52:03 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-02-07 16:56:02 +01:00
|
|
|
bool SyntaxHighlighter::is_identifier(void* token) const
|
2020-03-13 00:52:03 +02:00
|
|
|
{
|
|
|
|
auto js_token = static_cast<JS::TokenType>(reinterpret_cast<size_t>(token));
|
|
|
|
return js_token == JS::TokenType::Identifier;
|
|
|
|
}
|
|
|
|
|
2021-02-07 16:56:02 +01:00
|
|
|
bool SyntaxHighlighter::is_navigatable([[maybe_unused]] void* token) const
|
2020-03-13 00:52:03 +02:00
|
|
|
{
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2021-02-07 16:56:02 +01:00
|
|
|
void SyntaxHighlighter::rehighlight(Gfx::Palette palette)
|
2020-03-13 00:52:03 +02:00
|
|
|
{
|
2021-02-07 16:56:02 +01:00
|
|
|
auto text = m_client->get_text();
|
2020-03-13 00:52:03 +02:00
|
|
|
|
|
|
|
JS::Lexer lexer(text);
|
|
|
|
|
|
|
|
Vector<GUI::TextDocumentSpan> spans;
|
|
|
|
GUI::TextPosition position { 0, 0 };
|
|
|
|
GUI::TextPosition start { 0, 0 };
|
|
|
|
|
2020-03-16 01:05:06 +02:00
|
|
|
auto advance_position = [&position](char ch) {
|
2020-03-13 00:52:03 +02:00
|
|
|
if (ch == '\n') {
|
|
|
|
position.set_line(position.line() + 1);
|
|
|
|
position.set_column(0);
|
|
|
|
} else
|
|
|
|
position.set_column(position.column() + 1);
|
|
|
|
};
|
|
|
|
|
2020-03-16 01:05:06 +02:00
|
|
|
auto append_token = [&](StringView str, const JS::Token& token, bool is_trivia) {
|
|
|
|
if (str.is_empty())
|
|
|
|
return;
|
2020-03-13 00:52:03 +02:00
|
|
|
|
|
|
|
start = position;
|
2020-03-16 01:05:06 +02:00
|
|
|
for (size_t i = 0; i < str.length() - 1; ++i)
|
|
|
|
advance_position(str[i]);
|
|
|
|
|
|
|
|
GUI::TextDocumentSpan span;
|
|
|
|
span.range.set_start(start);
|
|
|
|
span.range.set_end({ position.line(), position.column() });
|
|
|
|
auto type = is_trivia ? JS::TokenType::Invalid : token.type();
|
|
|
|
auto style = style_for_token_type(palette, type);
|
2021-01-02 20:31:45 +01:00
|
|
|
span.attributes.color = style.color;
|
|
|
|
span.attributes.bold = style.bold;
|
2020-03-16 01:05:06 +02:00
|
|
|
span.is_skippable = is_trivia;
|
|
|
|
span.data = reinterpret_cast<void*>(static_cast<size_t>(type));
|
|
|
|
spans.append(span);
|
|
|
|
advance_position(str[str.length() - 1]);
|
|
|
|
|
2021-01-23 23:59:27 +01:00
|
|
|
dbgln<SYNTAX_HIGHLIGHTING_DEBUG>("{}{} @ '{}' {}:{} - {}:{}",
|
2021-01-16 15:51:56 +01:00
|
|
|
token.name(),
|
|
|
|
is_trivia ? " (trivia)" : "",
|
|
|
|
token.value(),
|
|
|
|
span.range.start().line(), span.range.start().column(),
|
|
|
|
span.range.end().line(), span.range.end().column());
|
2020-03-16 01:05:06 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
bool was_eof = false;
|
|
|
|
for (auto token = lexer.next(); !was_eof; token = lexer.next()) {
|
|
|
|
append_token(token.trivia(), token, true);
|
|
|
|
append_token(token.value(), token, false);
|
2020-03-13 00:52:03 +02:00
|
|
|
|
|
|
|
if (token.type() == JS::TokenType::Eof)
|
|
|
|
was_eof = true;
|
|
|
|
}
|
|
|
|
|
2021-02-07 16:56:02 +01:00
|
|
|
m_client->do_set_spans(move(spans));
|
2020-03-13 00:52:03 +02:00
|
|
|
|
|
|
|
m_has_brace_buddies = false;
|
|
|
|
highlight_matching_token_pair();
|
|
|
|
|
2021-02-07 16:56:02 +01:00
|
|
|
m_client->do_update();
|
2020-03-13 00:52:03 +02:00
|
|
|
}
|
|
|
|
|
2021-02-07 16:56:02 +01:00
|
|
|
Vector<Syntax::Highlighter::MatchingTokenPair> SyntaxHighlighter::matching_token_pairs() const
|
2020-03-13 00:52:03 +02:00
|
|
|
{
|
2021-02-07 15:15:10 +01:00
|
|
|
static Vector<Syntax::Highlighter::MatchingTokenPair> pairs;
|
2020-03-13 00:52:03 +02:00
|
|
|
if (pairs.is_empty()) {
|
|
|
|
pairs.append({ reinterpret_cast<void*>(JS::TokenType::CurlyOpen), reinterpret_cast<void*>(JS::TokenType::CurlyClose) });
|
|
|
|
pairs.append({ reinterpret_cast<void*>(JS::TokenType::ParenOpen), reinterpret_cast<void*>(JS::TokenType::ParenClose) });
|
|
|
|
pairs.append({ reinterpret_cast<void*>(JS::TokenType::BracketOpen), reinterpret_cast<void*>(JS::TokenType::BracketClose) });
|
|
|
|
}
|
|
|
|
return pairs;
|
|
|
|
}
|
|
|
|
|
2021-02-07 16:56:02 +01:00
|
|
|
bool SyntaxHighlighter::token_types_equal(void* token1, void* token2) const
|
2020-03-13 00:52:03 +02:00
|
|
|
{
|
|
|
|
return static_cast<JS::TokenType>(reinterpret_cast<size_t>(token1)) == static_cast<JS::TokenType>(reinterpret_cast<size_t>(token2));
|
|
|
|
}
|
|
|
|
|
2021-02-07 16:56:02 +01:00
|
|
|
SyntaxHighlighter::~SyntaxHighlighter()
|
2020-03-13 00:52:03 +02:00
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
}
|