2020-05-25 19:24:46 +00:00
|
|
|
/*
|
2020-05-25 15:46:10 +00:00
|
|
|
* Copyright (c) 2020, Hunter Salyer <thefalsehonesty@gmail.com>
|
|
|
|
*
|
2021-04-22 08:24:48 +00:00
|
|
|
* SPDX-License-Identifier: BSD-2-Clause
|
2020-05-25 15:46:10 +00:00
|
|
|
*/
|
2020-05-25 19:24:46 +00:00
|
|
|
|
|
|
|
#include <AK/HashTable.h>
|
|
|
|
#include <AK/StringBuilder.h>
|
2021-07-31 07:43:42 +00:00
|
|
|
#include <AK/TypeCasts.h>
|
2020-05-25 19:24:46 +00:00
|
|
|
#include <LibJS/Lexer.h>
|
|
|
|
#include <LibJS/MarkupGenerator.h>
|
|
|
|
#include <LibJS/Runtime/Array.h>
|
|
|
|
#include <LibJS/Runtime/Date.h>
|
2022-01-14 22:55:11 +00:00
|
|
|
#include <LibJS/Runtime/DatePrototype.h>
|
2020-05-25 19:24:46 +00:00
|
|
|
#include <LibJS/Runtime/Error.h>
|
|
|
|
#include <LibJS/Runtime/Object.h>
|
2021-07-03 21:28:40 +00:00
|
|
|
#include <LibJS/Runtime/VM.h>
|
2020-05-25 19:24:46 +00:00
|
|
|
|
|
|
|
namespace JS {
|
|
|
|
|
2022-12-06 20:42:59 +00:00
|
|
|
ErrorOr<String> MarkupGenerator::html_from_source(StringView source)
|
2020-05-25 19:24:46 +00:00
|
|
|
{
|
|
|
|
StringBuilder builder;
|
2020-05-25 15:46:10 +00:00
|
|
|
auto lexer = Lexer(source);
|
2020-05-25 19:24:46 +00:00
|
|
|
for (auto token = lexer.next(); token.type() != TokenType::Eof; token = lexer.next()) {
|
2022-12-06 20:42:59 +00:00
|
|
|
TRY(builder.try_append(token.trivia()));
|
|
|
|
TRY(builder.try_append(TRY(wrap_string_in_style(token.value(), style_type_for_token(token)))));
|
2020-05-25 19:24:46 +00:00
|
|
|
}
|
2022-12-06 20:42:59 +00:00
|
|
|
return builder.to_string();
|
2020-05-25 19:24:46 +00:00
|
|
|
}
|
|
|
|
|
2022-12-06 20:42:59 +00:00
|
|
|
ErrorOr<String> MarkupGenerator::html_from_value(Value value)
|
2020-05-25 19:24:46 +00:00
|
|
|
{
|
|
|
|
StringBuilder output_html;
|
2022-12-06 20:42:59 +00:00
|
|
|
TRY(value_to_html(value, output_html));
|
|
|
|
return output_html.to_string();
|
2020-05-25 19:24:46 +00:00
|
|
|
}
|
|
|
|
|
2022-12-06 20:42:59 +00:00
|
|
|
ErrorOr<String> MarkupGenerator::html_from_error(Error const& object, bool in_promise)
|
2021-04-11 22:08:28 +00:00
|
|
|
{
|
|
|
|
StringBuilder output_html;
|
2022-12-06 20:42:59 +00:00
|
|
|
TRY(error_to_html(object, output_html, in_promise));
|
|
|
|
return output_html.to_string();
|
2021-04-11 22:08:28 +00:00
|
|
|
}
|
|
|
|
|
2022-12-06 20:42:59 +00:00
|
|
|
ErrorOr<void> MarkupGenerator::value_to_html(Value value, StringBuilder& output_html, HashTable<Object*> seen_objects)
|
2020-05-25 19:24:46 +00:00
|
|
|
{
|
|
|
|
if (value.is_empty()) {
|
2022-12-06 20:42:59 +00:00
|
|
|
TRY(output_html.try_append("<empty>"sv));
|
|
|
|
return {};
|
2020-05-25 19:24:46 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
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.
|
2022-12-06 20:42:59 +00:00
|
|
|
TRY(output_html.try_appendff("<already printed Object {:p}>", &value.as_object()));
|
|
|
|
return {};
|
2020-05-25 19:24:46 +00:00
|
|
|
}
|
|
|
|
seen_objects.set(&value.as_object());
|
|
|
|
}
|
|
|
|
|
|
|
|
if (value.is_object()) {
|
|
|
|
auto& object = value.as_object();
|
2021-07-05 17:58:51 +00:00
|
|
|
if (is<Array>(object))
|
2022-04-01 17:58:27 +00:00
|
|
|
return array_to_html(static_cast<Array const&>(object), output_html, seen_objects);
|
2022-12-06 20:42:59 +00:00
|
|
|
TRY(output_html.try_append(TRY(wrap_string_in_style(object.class_name(), StyleType::ObjectType))));
|
2020-05-25 19:24:46 +00:00
|
|
|
if (object.is_function())
|
|
|
|
return function_to_html(object, output_html, seen_objects);
|
2021-01-01 16:46:39 +00:00
|
|
|
if (is<Date>(object))
|
2020-05-25 19:24:46 +00:00
|
|
|
return date_to_html(object, output_html, seen_objects);
|
|
|
|
return object_to_html(object, output_html, seen_objects);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (value.is_string())
|
2022-12-06 20:42:59 +00:00
|
|
|
TRY(output_html.try_append(TRY(open_style_type(StyleType::String))));
|
2020-05-25 19:24:46 +00:00
|
|
|
else if (value.is_number())
|
2022-12-06 20:42:59 +00:00
|
|
|
TRY(output_html.try_append(TRY(open_style_type(StyleType::Number))));
|
2020-10-02 14:00:15 +00:00
|
|
|
else if (value.is_boolean() || value.is_nullish())
|
2022-12-06 20:42:59 +00:00
|
|
|
TRY(output_html.try_append(TRY(open_style_type(StyleType::KeywordBold))));
|
2020-05-25 19:24:46 +00:00
|
|
|
|
|
|
|
if (value.is_string())
|
2022-12-06 20:42:59 +00:00
|
|
|
TRY(output_html.try_append('"'));
|
2023-02-13 02:54:02 +00:00
|
|
|
TRY(output_html.try_append(escape_html_entities(TRY(value.to_string_without_side_effects()))));
|
2020-05-25 19:24:46 +00:00
|
|
|
if (value.is_string())
|
2022-12-06 20:42:59 +00:00
|
|
|
TRY(output_html.try_append('"'));
|
2020-05-25 19:24:46 +00:00
|
|
|
|
2022-12-06 20:42:59 +00:00
|
|
|
TRY(output_html.try_append("</span>"sv));
|
|
|
|
return {};
|
2020-05-25 19:24:46 +00:00
|
|
|
}
|
|
|
|
|
2022-12-06 20:42:59 +00:00
|
|
|
ErrorOr<void> MarkupGenerator::array_to_html(Array const& array, StringBuilder& html_output, HashTable<Object*>& seen_objects)
|
2020-05-25 19:24:46 +00:00
|
|
|
{
|
2022-12-06 20:42:59 +00:00
|
|
|
TRY(html_output.try_append(TRY(wrap_string_in_style("[ "sv, 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 18:35:09 +00:00
|
|
|
bool first = true;
|
|
|
|
for (auto it = array.indexed_properties().begin(false); it != array.indexed_properties().end(); ++it) {
|
|
|
|
if (!first)
|
2022-12-06 20:42:59 +00:00
|
|
|
TRY(html_output.try_append(TRY(wrap_string_in_style(", "sv, 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 18:35:09 +00:00
|
|
|
first = false;
|
|
|
|
// FIXME: Exception check
|
2022-12-06 20:42:59 +00:00
|
|
|
TRY(value_to_html(array.get(it.index()).release_value(), html_output, seen_objects));
|
2020-05-25 19:24:46 +00:00
|
|
|
}
|
2022-12-06 20:42:59 +00:00
|
|
|
TRY(html_output.try_append(TRY(wrap_string_in_style(" ]"sv, StyleType::Punctuation))));
|
|
|
|
return {};
|
2020-05-25 19:24:46 +00:00
|
|
|
}
|
|
|
|
|
2022-12-06 20:42:59 +00:00
|
|
|
ErrorOr<void> MarkupGenerator::object_to_html(Object const& object, StringBuilder& html_output, HashTable<Object*>& seen_objects)
|
2020-05-25 19:24:46 +00:00
|
|
|
{
|
2022-12-06 20:42:59 +00:00
|
|
|
TRY(html_output.try_append(TRY(wrap_string_in_style("{ "sv, 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 18:35:09 +00:00
|
|
|
bool first = true;
|
|
|
|
for (auto& entry : object.indexed_properties()) {
|
|
|
|
if (!first)
|
2022-12-06 20:42:59 +00:00
|
|
|
TRY(html_output.try_append(TRY(wrap_string_in_style(", "sv, 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 18:35:09 +00:00
|
|
|
first = false;
|
2022-12-06 20:42:59 +00:00
|
|
|
TRY(html_output.try_append(TRY(wrap_string_in_style(TRY(String::number(entry.index())), StyleType::Number))));
|
|
|
|
TRY(html_output.try_append(TRY(wrap_string_in_style(": "sv, 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 18:35:09 +00:00
|
|
|
// FIXME: Exception check
|
2022-12-06 20:42:59 +00:00
|
|
|
TRY(value_to_html(object.get(entry.index()).release_value(), html_output, seen_objects));
|
2020-05-25 19:24:46 +00: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 18:35:09 +00:00
|
|
|
if (!object.indexed_properties().is_empty() && object.shape().property_count())
|
2022-12-06 20:42:59 +00:00
|
|
|
TRY(html_output.try_append(TRY(wrap_string_in_style(", "sv, StyleType::Punctuation))));
|
2020-05-25 19:24:46 +00:00
|
|
|
|
|
|
|
size_t index = 0;
|
|
|
|
for (auto& it : object.shape().property_table_ordered()) {
|
2022-12-06 20:42:59 +00:00
|
|
|
TRY(html_output.try_append(TRY(wrap_string_in_style(TRY(String::formatted("\"{}\"", escape_html_entities(it.key.to_display_string()))), StyleType::String))));
|
|
|
|
TRY(html_output.try_append(TRY(wrap_string_in_style(": "sv, StyleType::Punctuation))));
|
|
|
|
TRY(value_to_html(object.get_direct(it.value.offset), html_output, seen_objects));
|
2020-05-25 19:24:46 +00:00
|
|
|
if (index != object.shape().property_count() - 1)
|
2022-12-06 20:42:59 +00:00
|
|
|
TRY(html_output.try_append(TRY(wrap_string_in_style(", "sv, StyleType::Punctuation))));
|
2020-05-25 19:24:46 +00:00
|
|
|
++index;
|
|
|
|
}
|
|
|
|
|
2022-12-06 20:42:59 +00:00
|
|
|
TRY(html_output.try_append(TRY(wrap_string_in_style(" }"sv, StyleType::Punctuation))));
|
|
|
|
return {};
|
2020-05-25 19:24:46 +00:00
|
|
|
}
|
|
|
|
|
2022-12-06 20:42:59 +00:00
|
|
|
ErrorOr<void> MarkupGenerator::function_to_html(Object const& function, StringBuilder& html_output, HashTable<Object*>&)
|
2020-05-25 19:24:46 +00:00
|
|
|
{
|
2022-12-06 20:42:59 +00:00
|
|
|
TRY(html_output.try_appendff("[{}]", function.class_name()));
|
|
|
|
return {};
|
2020-05-25 19:24:46 +00:00
|
|
|
}
|
|
|
|
|
2022-12-06 20:42:59 +00:00
|
|
|
ErrorOr<void> MarkupGenerator::date_to_html(Object const& date, StringBuilder& html_output, HashTable<Object*>&)
|
2020-05-25 19:24:46 +00:00
|
|
|
{
|
2022-12-06 20:42:59 +00:00
|
|
|
TRY(html_output.try_appendff("Date {}", to_date_string(static_cast<Date const&>(date).date_value())));
|
|
|
|
return {};
|
2020-05-25 19:24:46 +00:00
|
|
|
}
|
|
|
|
|
2022-12-06 20:42:59 +00:00
|
|
|
ErrorOr<void> MarkupGenerator::trace_to_html(TracebackFrame const& traceback_frame, StringBuilder& html_output)
|
2020-05-25 19:24:46 +00:00
|
|
|
{
|
2022-10-08 15:38:32 +00:00
|
|
|
auto function_name = escape_html_entities(traceback_frame.function_name);
|
2023-05-28 06:28:43 +00:00
|
|
|
auto [line, column, _] = traceback_frame.source_range().start;
|
2022-10-08 15:38:32 +00:00
|
|
|
auto get_filename_from_path = [&](StringView filename) -> StringView {
|
|
|
|
auto last_slash_index = filename.find_last('/');
|
|
|
|
return last_slash_index.has_value() ? filename.substring_view(*last_slash_index + 1) : filename;
|
|
|
|
};
|
2023-05-28 06:28:43 +00:00
|
|
|
auto filename = escape_html_entities(get_filename_from_path(traceback_frame.source_range().filename()));
|
2022-12-06 20:42:59 +00:00
|
|
|
auto trace = TRY(String::formatted("at {} ({}:{}:{})", function_name, filename, line, column));
|
2022-10-08 15:38:32 +00:00
|
|
|
|
2022-12-06 20:42:59 +00:00
|
|
|
TRY(html_output.try_appendff(" {}<br>", trace));
|
|
|
|
return {};
|
2022-10-08 15:38:32 +00:00
|
|
|
}
|
|
|
|
|
2022-12-06 20:42:59 +00:00
|
|
|
ErrorOr<void> MarkupGenerator::error_to_html(Error const& error, StringBuilder& html_output, bool in_promise)
|
2022-10-08 15:38:32 +00:00
|
|
|
{
|
|
|
|
auto& vm = error.vm();
|
|
|
|
auto name = error.get_without_side_effects(vm.names.name).value_or(js_undefined());
|
|
|
|
auto message = error.get_without_side_effects(vm.names.message).value_or(js_undefined());
|
2023-02-13 02:54:02 +00:00
|
|
|
auto name_string = TRY(name.to_string_without_side_effects());
|
|
|
|
auto message_string = TRY(message.to_string_without_side_effects());
|
2022-12-06 20:42:59 +00:00
|
|
|
auto uncaught_message = TRY(String::formatted("Uncaught {}[{}]: ", in_promise ? "(in promise) " : "", name_string));
|
2022-10-08 15:38:32 +00:00
|
|
|
|
2022-12-06 20:42:59 +00:00
|
|
|
TRY(html_output.try_append(TRY(wrap_string_in_style(uncaught_message, StyleType::Invalid)).bytes_as_string_view()));
|
|
|
|
TRY(html_output.try_appendff("{}<br>", message_string.is_empty() ? "\"\"" : escape_html_entities(message_string)));
|
2022-10-08 15:38:32 +00:00
|
|
|
|
|
|
|
for (size_t i = 0; i < error.traceback().size() - min(error.traceback().size(), 3); i++) {
|
|
|
|
auto& traceback_frame = error.traceback().at(i);
|
2022-12-06 20:42:59 +00:00
|
|
|
TRY(trace_to_html(traceback_frame, html_output));
|
2020-05-25 19:24:46 +00:00
|
|
|
}
|
2022-12-06 20:42:59 +00:00
|
|
|
return {};
|
2020-05-25 19:24:46 +00:00
|
|
|
}
|
|
|
|
|
2022-12-06 20:42:59 +00:00
|
|
|
StringView MarkupGenerator::style_from_style_type(StyleType type)
|
2020-05-25 19:24:46 +00:00
|
|
|
{
|
|
|
|
switch (type) {
|
|
|
|
case StyleType::Invalid:
|
2022-12-06 20:42:59 +00:00
|
|
|
return "color: red;"sv;
|
2020-05-25 19:24:46 +00:00
|
|
|
case StyleType::String:
|
2022-12-06 20:42:59 +00:00
|
|
|
return "color: -libweb-palette-syntax-string;"sv;
|
2020-05-25 19:24:46 +00:00
|
|
|
case StyleType::Number:
|
2022-12-06 20:42:59 +00:00
|
|
|
return "color: -libweb-palette-syntax-number;"sv;
|
2020-05-25 19:24:46 +00:00
|
|
|
case StyleType::KeywordBold:
|
2022-12-06 20:42:59 +00:00
|
|
|
return "color: -libweb-palette-syntax-keyword; font-weight: bold;"sv;
|
2020-05-25 19:24:46 +00:00
|
|
|
case StyleType::Punctuation:
|
2022-12-06 20:42:59 +00:00
|
|
|
return "color: -libweb-palette-syntax-punctuation;"sv;
|
2020-05-25 19:24:46 +00:00
|
|
|
case StyleType::Operator:
|
2022-12-06 20:42:59 +00:00
|
|
|
return "color: -libweb-palette-syntax-operator;"sv;
|
2020-05-25 19:24:46 +00:00
|
|
|
case StyleType::Keyword:
|
2022-12-06 20:42:59 +00:00
|
|
|
return "color: -libweb-palette-syntax-keyword;"sv;
|
2020-05-25 19:24:46 +00:00
|
|
|
case StyleType::ControlKeyword:
|
2022-12-06 20:42:59 +00:00
|
|
|
return "color: -libweb-palette-syntax-control-keyword;"sv;
|
2020-05-25 19:24:46 +00:00
|
|
|
case StyleType::Identifier:
|
2022-12-06 20:42:59 +00:00
|
|
|
return "color: -libweb-palette-syntax-identifier;"sv;
|
2021-04-20 09:41:59 +00:00
|
|
|
case StyleType::ObjectType:
|
2022-12-06 20:42:59 +00:00
|
|
|
return "padding: 2px; background-color: #ddf; color: black; font-weight: bold;"sv;
|
2020-05-25 19:24:46 +00:00
|
|
|
default:
|
2021-02-23 19:42:32 +00:00
|
|
|
VERIFY_NOT_REACHED();
|
2020-05-25 19:24:46 +00: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 21:28:59 +00:00
|
|
|
switch (token.category()) {
|
|
|
|
case TokenCategory::Invalid:
|
2020-05-25 19:24:46 +00: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 21:28:59 +00:00
|
|
|
case TokenCategory::Number:
|
2020-05-25 19:24:46 +00: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 21:28:59 +00:00
|
|
|
case TokenCategory::String:
|
2020-05-25 19:24:46 +00: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 21:28:59 +00:00
|
|
|
case TokenCategory::Punctuation:
|
2020-05-25 19:24:46 +00: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 21:28:59 +00:00
|
|
|
case TokenCategory::Operator:
|
2020-05-25 19:24:46 +00: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 21:28:59 +00: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 19:24:46 +00: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 21:28:59 +00:00
|
|
|
case TokenCategory::Identifier:
|
2020-05-25 19:24:46 +00:00
|
|
|
return StyleType::Identifier;
|
|
|
|
default:
|
2020-10-04 14:44:40 +00:00
|
|
|
dbgln("Unknown style type for token {}", token.name());
|
2021-02-23 19:42:32 +00:00
|
|
|
VERIFY_NOT_REACHED();
|
2020-05-25 19:24:46 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-12-06 20:42:59 +00:00
|
|
|
ErrorOr<String> MarkupGenerator::open_style_type(StyleType type)
|
2020-05-25 19:24:46 +00:00
|
|
|
{
|
2022-12-06 20:42:59 +00:00
|
|
|
return String::formatted("<span style=\"{}\">", style_from_style_type(type));
|
2020-05-25 19:24:46 +00:00
|
|
|
}
|
|
|
|
|
2022-12-06 20:42:59 +00:00
|
|
|
ErrorOr<String> MarkupGenerator::wrap_string_in_style(StringView source, StyleType type)
|
2020-05-25 19:24:46 +00:00
|
|
|
{
|
2022-12-06 20:42:59 +00:00
|
|
|
return String::formatted("<span style=\"{}\">{}</span>", style_from_style_type(type), escape_html_entities(source));
|
2020-05-25 19:24:46 +00:00
|
|
|
}
|
|
|
|
|
2020-05-26 17:00:30 +00:00
|
|
|
}
|