2020-05-25 15:24:46 -04:00
|
|
|
/*
|
2020-05-25 11:46:10 -04:00
|
|
|
* Copyright (c) 2020, Hunter Salyer <thefalsehonesty@gmail.com>
|
|
|
|
*
|
2021-04-22 01:24:48 -07:00
|
|
|
* SPDX-License-Identifier: BSD-2-Clause
|
2020-05-25 11:46:10 -04:00
|
|
|
*/
|
2020-05-25 15:24:46 -04:00
|
|
|
|
|
|
|
#include <AK/HashTable.h>
|
|
|
|
#include <AK/StringBuilder.h>
|
|
|
|
#include <LibJS/Lexer.h>
|
|
|
|
#include <LibJS/MarkupGenerator.h>
|
|
|
|
#include <LibJS/Runtime/Array.h>
|
|
|
|
#include <LibJS/Runtime/Date.h>
|
|
|
|
#include <LibJS/Runtime/Error.h>
|
|
|
|
#include <LibJS/Runtime/Object.h>
|
2021-07-03 22:28:40 +01:00
|
|
|
#include <LibJS/Runtime/VM.h>
|
2020-05-25 15:24:46 -04:00
|
|
|
|
|
|
|
namespace JS {
|
|
|
|
|
2020-05-25 11:46:10 -04:00
|
|
|
String MarkupGenerator::html_from_source(const StringView& source)
|
2020-05-25 15:24:46 -04:00
|
|
|
{
|
|
|
|
StringBuilder builder;
|
2020-05-25 11:46:10 -04:00
|
|
|
auto lexer = Lexer(source);
|
2020-05-25 15:24:46 -04:00
|
|
|
for (auto token = lexer.next(); token.type() != TokenType::Eof; token = lexer.next()) {
|
2020-10-31 17:25:29 +00:00
|
|
|
builder.append(token.trivia());
|
2020-05-25 15:24:46 -04:00
|
|
|
builder.append(wrap_string_in_style(token.value(), style_type_for_token(token)));
|
|
|
|
}
|
|
|
|
return builder.to_string();
|
|
|
|
}
|
|
|
|
|
|
|
|
String MarkupGenerator::html_from_value(Value value)
|
|
|
|
{
|
|
|
|
StringBuilder output_html;
|
|
|
|
value_to_html(value, output_html);
|
|
|
|
return output_html.to_string();
|
|
|
|
}
|
|
|
|
|
2021-04-12 00:08:28 +02:00
|
|
|
String MarkupGenerator::html_from_error(Object& object)
|
|
|
|
{
|
|
|
|
StringBuilder output_html;
|
|
|
|
HashTable<Object*> seen_objects;
|
|
|
|
error_to_html(object, output_html, seen_objects);
|
|
|
|
return output_html.to_string();
|
|
|
|
}
|
|
|
|
|
2020-05-25 15:24:46 -04:00
|
|
|
void MarkupGenerator::value_to_html(Value value, StringBuilder& output_html, HashTable<Object*> seen_objects)
|
|
|
|
{
|
|
|
|
if (value.is_empty()) {
|
|
|
|
output_html.append("<empty>");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (value.is_object()) {
|
|
|
|
if (seen_objects.contains(&value.as_object())) {
|
|
|
|
// FIXME: Maybe we should only do this for circular references,
|
|
|
|
// not for all reoccurring objects.
|
2020-10-04 13:34:25 +01:00
|
|
|
output_html.appendff("<already printed Object {:p}>", &value.as_object());
|
2020-05-25 15:24:46 -04:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
seen_objects.set(&value.as_object());
|
|
|
|
}
|
|
|
|
|
|
|
|
if (value.is_object()) {
|
|
|
|
auto& object = value.as_object();
|
2021-07-05 18:58:51 +01:00
|
|
|
if (is<Array>(object))
|
2021-06-08 21:53:36 +01:00
|
|
|
return array_to_html(static_cast<const Array&>(object), output_html, seen_objects);
|
2021-04-20 11:41:59 +02:00
|
|
|
output_html.append(wrap_string_in_style(object.class_name(), StyleType::ObjectType));
|
2020-05-25 15:24:46 -04:00
|
|
|
if (object.is_function())
|
|
|
|
return function_to_html(object, output_html, seen_objects);
|
2021-01-01 17:46:39 +01:00
|
|
|
if (is<Date>(object))
|
2020-05-25 15:24:46 -04:00
|
|
|
return date_to_html(object, output_html, seen_objects);
|
2021-01-01 17:46:39 +01:00
|
|
|
if (is<Error>(object))
|
2020-05-25 15:24:46 -04:00
|
|
|
return error_to_html(object, output_html, seen_objects);
|
|
|
|
return object_to_html(object, output_html, seen_objects);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (value.is_string())
|
|
|
|
output_html.append(open_style_type(StyleType::String));
|
|
|
|
else if (value.is_number())
|
|
|
|
output_html.append(open_style_type(StyleType::Number));
|
2020-10-02 16:00:15 +02:00
|
|
|
else if (value.is_boolean() || value.is_nullish())
|
2020-05-25 15:24:46 -04:00
|
|
|
output_html.append(open_style_type(StyleType::KeywordBold));
|
|
|
|
|
|
|
|
if (value.is_string())
|
|
|
|
output_html.append('"');
|
2020-07-22 21:43:08 -04:00
|
|
|
output_html.append(escape_html_entities(value.to_string_without_side_effects()));
|
2020-05-25 15:24:46 -04:00
|
|
|
if (value.is_string())
|
|
|
|
output_html.append('"');
|
|
|
|
|
|
|
|
output_html.append("</span>");
|
|
|
|
}
|
|
|
|
|
|
|
|
void MarkupGenerator::array_to_html(const Array& array, StringBuilder& html_output, HashTable<Object*>& seen_objects)
|
|
|
|
{
|
|
|
|
html_output.append(wrap_string_in_style("[ ", StyleType::Punctuation));
|
LibJS: Object index properties have descriptors; Handle sparse indices
This patch adds an IndexedProperties object for storing indexed
properties within an Object. This accomplishes two goals: indexed
properties now have an associated descriptor, and objects now gracefully
handle sparse properties.
The IndexedProperties class is a wrapper around two other classes, one
for simple indexed properties storage, and one for general indexed
property storage. Simple indexed property storage is the common-case,
and is simply a vector of properties which all have attributes of
default_attributes (writable, enumerable, and configurable).
General indexed property storage is for a collection of indexed
properties where EITHER one or more properties have attributes other
than default_attributes OR there is a property with a large index (in
particular, large is '200' or higher).
Indexed properties are now treated relatively the same as storage within
the various Object methods. Additionally, there is a custom iterator
class for IndexedProperties which makes iteration easy. The iterator
skips empty values by default, but can be configured otherwise.
Likewise, it evaluates getters by default, but can be set not to.
2020-05-27 11:35:09 -07:00
|
|
|
bool first = true;
|
|
|
|
for (auto it = array.indexed_properties().begin(false); it != array.indexed_properties().end(); ++it) {
|
|
|
|
if (!first)
|
2020-05-25 15:24:46 -04:00
|
|
|
html_output.append(wrap_string_in_style(", ", StyleType::Punctuation));
|
LibJS: Object index properties have descriptors; Handle sparse indices
This patch adds an IndexedProperties object for storing indexed
properties within an Object. This accomplishes two goals: indexed
properties now have an associated descriptor, and objects now gracefully
handle sparse properties.
The IndexedProperties class is a wrapper around two other classes, one
for simple indexed properties storage, and one for general indexed
property storage. Simple indexed property storage is the common-case,
and is simply a vector of properties which all have attributes of
default_attributes (writable, enumerable, and configurable).
General indexed property storage is for a collection of indexed
properties where EITHER one or more properties have attributes other
than default_attributes OR there is a property with a large index (in
particular, large is '200' or higher).
Indexed properties are now treated relatively the same as storage within
the various Object methods. Additionally, there is a custom iterator
class for IndexedProperties which makes iteration easy. The iterator
skips empty values by default, but can be configured otherwise.
Likewise, it evaluates getters by default, but can be set not to.
2020-05-27 11:35:09 -07:00
|
|
|
first = false;
|
|
|
|
// FIXME: Exception check
|
LibJS: Rewrite most of Object for spec compliance :^)
This is a huge patch, I know. In hindsight this perhaps could've been
done slightly more incremental, but I started and then fixed everything
until it worked, and here we are. I tried splitting of some completely
unrelated changes into separate commits, however. Anyway.
This is a rewrite of most of Object, and by extension large parts of
Array, Proxy, Reflect, String, TypedArray, and some other things.
What we already had worked fine for about 90% of things, but getting the
last 10% right proved to be increasingly difficult with the current code
that sort of grew organically and is only very loosely based on the
spec - this became especially obvious when we started fixing a large
number of test262 failures.
Key changes include:
- 1:1 matching function names and parameters of all object-related
functions, to avoid ambiguity. Previously we had things like put(),
which the spec doesn't have - as a result it wasn't always clear which
need to be used.
- Better separation between object abstract operations and internal
methods - the former are always the same, the latter can be overridden
(and are therefore virtual). The internal methods (i.e. [[Foo]] in the
spec) are now prefixed with 'internal_' for clarity - again, it was
previously not always clear which AO a certain method represents,
get() could've been both Get and [[Get]] (I don't know which one it
was closer to right now).
Note that some of the old names have been kept until all code relying
on them is updated, but they are now simple wrappers around the
closest matching standard abstract operation.
- Simplifications of the storage layer: functions that write values to
storage are now prefixed with 'storage_' to make their purpose clear,
and as they are not part of the spec they should not contain any steps
specified by it. Much functionality is now covered by the layers above
it and was removed (e.g. handling of accessors, attribute checks).
- PropertyAttributes has been greatly simplified, and is being replaced
by PropertyDescriptor - a concept similar to the current
implementation, but more aligned with the actual spec. See the commit
message of the previous commit where it was introduced for details.
- As a bonus, and since I had to look at the spec a whole lot anyway, I
introduced more inline comments with the exact steps from the spec -
this makes it super easy to verify correctness.
- East-const all the things.
As a result of all of this, things are much more correct but a bit
slower now. Retaining speed wasn't a consideration at all, I have done
no profiling of the new code - there might be low hanging fruits, which
we can then harvest separately.
Special thanks to Idan for helping me with this by tracking down bugs,
updating everything outside of LibJS to work with these changes (LibWeb,
Spreadsheet, HackStudio), as well as providing countless patches to fix
regressions I introduced - there still are very few (we got it down to
5), but we also get many new passing test262 tests in return. :^)
Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04 18:14:16 +01:00
|
|
|
value_to_html(array.get(it.index()), html_output, seen_objects);
|
2020-05-25 15:24:46 -04:00
|
|
|
}
|
|
|
|
html_output.append(wrap_string_in_style(" ]", StyleType::Punctuation));
|
|
|
|
}
|
|
|
|
|
|
|
|
void MarkupGenerator::object_to_html(const Object& object, StringBuilder& html_output, HashTable<Object*>& seen_objects)
|
|
|
|
{
|
|
|
|
html_output.append(wrap_string_in_style("{ ", StyleType::Punctuation));
|
LibJS: Object index properties have descriptors; Handle sparse indices
This patch adds an IndexedProperties object for storing indexed
properties within an Object. This accomplishes two goals: indexed
properties now have an associated descriptor, and objects now gracefully
handle sparse properties.
The IndexedProperties class is a wrapper around two other classes, one
for simple indexed properties storage, and one for general indexed
property storage. Simple indexed property storage is the common-case,
and is simply a vector of properties which all have attributes of
default_attributes (writable, enumerable, and configurable).
General indexed property storage is for a collection of indexed
properties where EITHER one or more properties have attributes other
than default_attributes OR there is a property with a large index (in
particular, large is '200' or higher).
Indexed properties are now treated relatively the same as storage within
the various Object methods. Additionally, there is a custom iterator
class for IndexedProperties which makes iteration easy. The iterator
skips empty values by default, but can be configured otherwise.
Likewise, it evaluates getters by default, but can be set not to.
2020-05-27 11:35:09 -07:00
|
|
|
bool first = true;
|
|
|
|
for (auto& entry : object.indexed_properties()) {
|
|
|
|
if (!first)
|
2020-05-25 15:24:46 -04:00
|
|
|
html_output.append(wrap_string_in_style(", ", StyleType::Punctuation));
|
LibJS: Object index properties have descriptors; Handle sparse indices
This patch adds an IndexedProperties object for storing indexed
properties within an Object. This accomplishes two goals: indexed
properties now have an associated descriptor, and objects now gracefully
handle sparse properties.
The IndexedProperties class is a wrapper around two other classes, one
for simple indexed properties storage, and one for general indexed
property storage. Simple indexed property storage is the common-case,
and is simply a vector of properties which all have attributes of
default_attributes (writable, enumerable, and configurable).
General indexed property storage is for a collection of indexed
properties where EITHER one or more properties have attributes other
than default_attributes OR there is a property with a large index (in
particular, large is '200' or higher).
Indexed properties are now treated relatively the same as storage within
the various Object methods. Additionally, there is a custom iterator
class for IndexedProperties which makes iteration easy. The iterator
skips empty values by default, but can be configured otherwise.
Likewise, it evaluates getters by default, but can be set not to.
2020-05-27 11:35:09 -07:00
|
|
|
first = false;
|
|
|
|
html_output.append(wrap_string_in_style(String::number(entry.index()), StyleType::Number));
|
|
|
|
html_output.append(wrap_string_in_style(": ", StyleType::Punctuation));
|
|
|
|
// FIXME: Exception check
|
LibJS: Rewrite most of Object for spec compliance :^)
This is a huge patch, I know. In hindsight this perhaps could've been
done slightly more incremental, but I started and then fixed everything
until it worked, and here we are. I tried splitting of some completely
unrelated changes into separate commits, however. Anyway.
This is a rewrite of most of Object, and by extension large parts of
Array, Proxy, Reflect, String, TypedArray, and some other things.
What we already had worked fine for about 90% of things, but getting the
last 10% right proved to be increasingly difficult with the current code
that sort of grew organically and is only very loosely based on the
spec - this became especially obvious when we started fixing a large
number of test262 failures.
Key changes include:
- 1:1 matching function names and parameters of all object-related
functions, to avoid ambiguity. Previously we had things like put(),
which the spec doesn't have - as a result it wasn't always clear which
need to be used.
- Better separation between object abstract operations and internal
methods - the former are always the same, the latter can be overridden
(and are therefore virtual). The internal methods (i.e. [[Foo]] in the
spec) are now prefixed with 'internal_' for clarity - again, it was
previously not always clear which AO a certain method represents,
get() could've been both Get and [[Get]] (I don't know which one it
was closer to right now).
Note that some of the old names have been kept until all code relying
on them is updated, but they are now simple wrappers around the
closest matching standard abstract operation.
- Simplifications of the storage layer: functions that write values to
storage are now prefixed with 'storage_' to make their purpose clear,
and as they are not part of the spec they should not contain any steps
specified by it. Much functionality is now covered by the layers above
it and was removed (e.g. handling of accessors, attribute checks).
- PropertyAttributes has been greatly simplified, and is being replaced
by PropertyDescriptor - a concept similar to the current
implementation, but more aligned with the actual spec. See the commit
message of the previous commit where it was introduced for details.
- As a bonus, and since I had to look at the spec a whole lot anyway, I
introduced more inline comments with the exact steps from the spec -
this makes it super easy to verify correctness.
- East-const all the things.
As a result of all of this, things are much more correct but a bit
slower now. Retaining speed wasn't a consideration at all, I have done
no profiling of the new code - there might be low hanging fruits, which
we can then harvest separately.
Special thanks to Idan for helping me with this by tracking down bugs,
updating everything outside of LibJS to work with these changes (LibWeb,
Spreadsheet, HackStudio), as well as providing countless patches to fix
regressions I introduced - there still are very few (we got it down to
5), but we also get many new passing test262 tests in return. :^)
Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04 18:14:16 +01:00
|
|
|
value_to_html(object.get(entry.index()), html_output, seen_objects);
|
2020-05-25 15:24:46 -04:00
|
|
|
}
|
|
|
|
|
LibJS: Object index properties have descriptors; Handle sparse indices
This patch adds an IndexedProperties object for storing indexed
properties within an Object. This accomplishes two goals: indexed
properties now have an associated descriptor, and objects now gracefully
handle sparse properties.
The IndexedProperties class is a wrapper around two other classes, one
for simple indexed properties storage, and one for general indexed
property storage. Simple indexed property storage is the common-case,
and is simply a vector of properties which all have attributes of
default_attributes (writable, enumerable, and configurable).
General indexed property storage is for a collection of indexed
properties where EITHER one or more properties have attributes other
than default_attributes OR there is a property with a large index (in
particular, large is '200' or higher).
Indexed properties are now treated relatively the same as storage within
the various Object methods. Additionally, there is a custom iterator
class for IndexedProperties which makes iteration easy. The iterator
skips empty values by default, but can be configured otherwise.
Likewise, it evaluates getters by default, but can be set not to.
2020-05-27 11:35:09 -07:00
|
|
|
if (!object.indexed_properties().is_empty() && object.shape().property_count())
|
2020-05-25 15:24:46 -04:00
|
|
|
html_output.append(wrap_string_in_style(", ", StyleType::Punctuation));
|
|
|
|
|
|
|
|
size_t index = 0;
|
|
|
|
for (auto& it : object.shape().property_table_ordered()) {
|
2020-10-04 13:34:25 +01:00
|
|
|
html_output.append(wrap_string_in_style(String::formatted("\"{}\"", escape_html_entities(it.key.to_display_string())), StyleType::String));
|
2020-05-25 15:24:46 -04:00
|
|
|
html_output.append(wrap_string_in_style(": ", StyleType::Punctuation));
|
|
|
|
value_to_html(object.get_direct(it.value.offset), html_output, seen_objects);
|
|
|
|
if (index != object.shape().property_count() - 1)
|
|
|
|
html_output.append(wrap_string_in_style(", ", StyleType::Punctuation));
|
|
|
|
++index;
|
|
|
|
}
|
|
|
|
|
|
|
|
html_output.append(wrap_string_in_style(" }", StyleType::Punctuation));
|
|
|
|
}
|
|
|
|
|
|
|
|
void MarkupGenerator::function_to_html(const Object& function, StringBuilder& html_output, HashTable<Object*>&)
|
|
|
|
{
|
2020-10-04 13:34:25 +01:00
|
|
|
html_output.appendff("[{}]", function.class_name());
|
2020-05-25 15:24:46 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
void MarkupGenerator::date_to_html(const Object& date, StringBuilder& html_output, HashTable<Object*>&)
|
|
|
|
{
|
2020-10-04 13:34:25 +01:00
|
|
|
html_output.appendff("Date {}", static_cast<const JS::Date&>(date).string());
|
2020-05-25 15:24:46 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
void MarkupGenerator::error_to_html(const Object& object, StringBuilder& html_output, HashTable<Object*>&)
|
|
|
|
{
|
2021-07-03 22:28:40 +01:00
|
|
|
auto& vm = object.vm();
|
|
|
|
auto name = object.get_without_side_effects(vm.names.name).value_or(JS::js_undefined());
|
|
|
|
auto message = object.get_without_side_effects(vm.names.message).value_or(JS::js_undefined());
|
2021-07-07 19:34:26 +03:00
|
|
|
if (name.is_accessor() || message.is_accessor()) {
|
2021-04-12 00:08:28 +02:00
|
|
|
html_output.append(wrap_string_in_style(JS::Value(&object).to_string_without_side_effects(), StyleType::Invalid));
|
|
|
|
} else {
|
|
|
|
auto name_string = name.to_string_without_side_effects();
|
|
|
|
auto message_string = message.to_string_without_side_effects();
|
|
|
|
html_output.append(wrap_string_in_style(String::formatted("[{}]", name_string), StyleType::Invalid));
|
|
|
|
if (!message_string.is_empty())
|
|
|
|
html_output.appendff(": {}", escape_html_entities(message_string));
|
2020-05-25 15:24:46 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
String MarkupGenerator::style_from_style_type(StyleType type)
|
|
|
|
{
|
|
|
|
switch (type) {
|
|
|
|
case StyleType::Invalid:
|
|
|
|
return "color: red;";
|
|
|
|
case StyleType::String:
|
|
|
|
return "color: -libweb-palette-syntax-string;";
|
|
|
|
case StyleType::Number:
|
|
|
|
return "color: -libweb-palette-syntax-number;";
|
|
|
|
case StyleType::KeywordBold:
|
|
|
|
return "color: -libweb-palette-syntax-keyword; font-weight: bold;";
|
|
|
|
case StyleType::Punctuation:
|
|
|
|
return "color: -libweb-palette-syntax-punctuation;";
|
|
|
|
case StyleType::Operator:
|
|
|
|
return "color: -libweb-palette-syntax-operator;";
|
|
|
|
case StyleType::Keyword:
|
|
|
|
return "color: -libweb-palette-syntax-keyword;";
|
|
|
|
case StyleType::ControlKeyword:
|
|
|
|
return "color: -libweb-palette-syntax-control-keyword;";
|
|
|
|
case StyleType::Identifier:
|
|
|
|
return "color: -libweb-palette-syntax-identifier;";
|
2021-04-20 11:41:59 +02:00
|
|
|
case StyleType::ObjectType:
|
|
|
|
return "padding: 2px; background-color: #ddf; color: black; font-weight: bold;";
|
2020-05-25 15:24:46 -04:00
|
|
|
default:
|
2021-02-23 20:42:32 +01:00
|
|
|
VERIFY_NOT_REACHED();
|
2020-05-25 15:24:46 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
MarkupGenerator::StyleType MarkupGenerator::style_type_for_token(Token token)
|
|
|
|
{
|
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 (token.category()) {
|
|
|
|
case TokenCategory::Invalid:
|
2020-05-25 15:24:46 -04:00
|
|
|
return StyleType::Invalid;
|
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 TokenCategory::Number:
|
2020-05-25 15:24:46 -04:00
|
|
|
return StyleType::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 TokenCategory::String:
|
2020-05-25 15:24:46 -04:00
|
|
|
return StyleType::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 TokenCategory::Punctuation:
|
2020-05-25 15:24:46 -04:00
|
|
|
return StyleType::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 TokenCategory::Operator:
|
2020-05-25 15:24:46 -04:00
|
|
|
return StyleType::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 TokenCategory::Keyword:
|
|
|
|
switch (token.type()) {
|
|
|
|
case TokenType::BoolLiteral:
|
|
|
|
case TokenType::NullLiteral:
|
|
|
|
return StyleType::KeywordBold;
|
|
|
|
default:
|
|
|
|
return StyleType::Keyword;
|
|
|
|
}
|
|
|
|
case TokenCategory::ControlKeyword:
|
2020-05-25 15:24:46 -04:00
|
|
|
return StyleType::ControlKeyword;
|
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 TokenCategory::Identifier:
|
2020-05-25 15:24:46 -04:00
|
|
|
return StyleType::Identifier;
|
|
|
|
default:
|
2020-10-04 15:44:40 +01:00
|
|
|
dbgln("Unknown style type for token {}", token.name());
|
2021-02-23 20:42:32 +01:00
|
|
|
VERIFY_NOT_REACHED();
|
2020-05-25 15:24:46 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
String MarkupGenerator::open_style_type(StyleType type)
|
|
|
|
{
|
2020-10-04 13:34:25 +01:00
|
|
|
return String::formatted("<span style=\"{}\">", style_from_style_type(type));
|
2020-05-25 15:24:46 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
String MarkupGenerator::wrap_string_in_style(String source, StyleType type)
|
|
|
|
{
|
2020-10-04 13:34:25 +01:00
|
|
|
return String::formatted("<span style=\"{}\">{}</span>", style_from_style_type(type), escape_html_entities(source));
|
2020-05-25 15:24:46 -04:00
|
|
|
}
|
|
|
|
|
2020-05-26 13:00:30 -04:00
|
|
|
}
|