We should always stay on the only line when selecting in a single-line
editor, instead of requiring the user to keep the cursor inside the
text when selecting.
This broke with the variable-width font changes.
Previously we would sometimes leave some pixels from an old selection
rect on screen after clearing the selection. It was because the line
content rect was smaller than the visual selection rect, and we were
using the line content rect for invalidations.
Oops, we can't be appending substrings of a string we just deleted!
Fix this by building up the new line instead of trying to clear and
append in place. This works out nicely as we now do fewer document view
updates when removing a range. :^)
Widgets can now opt in to emoji input via set_accepts_emoji_input().
If the focused widget accepts emoji input, we'll pop up a simple dialog
with all the available emojis as clickable buttons.
You can press escape if you change your mind and don't want an emoji.
This UI layout definitely will not scale as we add more emojis, but it
works for the moment, and we can adapt it as we go. Pretty cool! :^)
A TextDocumentLine is now backed by a non-null-terminated sequence of
Unicode codepoints encoded as UTF-32 (one u32 per codepoint.)
This makes it possible to view and edit arbitrary Unicode text without
strange cursor and selection behavior. You can freely copy and paste
emojis between TextEditor and Terminal now. :^)
Storing UTF-32 is quite space-inefficient, but we should be able to
use the same optimization techniques as LibVT does to reduce it in
the typical case where most text is ASCII.
There are a lot of things that can be cleaned up around this code,
but this works well enough that I'm pretty happy with it.
We will now actually use MIME types for clipboard. The default type is now
"text/plain" (instead of just "text").
This also fixes some issues in copy(1) and paste(1).
This commit moves the clipboard from WindowServer into a new Clipboard
service program. Clipboard runs as the unprivileged "clipboard" user
and with a much tighter pledge than WindowServer.
To keep things working as before, all GUI::Application users now make
a connection to Clipboard after making the connection to WindowServer.
It could be interesting to connect to Clipboard on demand, but right
now that would necessitate expanding every GUI app's pledge to include
"unix" and also unveiling the clipboard portal, which I prefer not to.
We were iterating the ancestor chain of the focused widget when looking
for a matching keyboard shortcut, but we didn't actually look at the
ancestors at each step.
With this fix, we now correctly activate actions found in the ancestor
chain of the focused widgets. :^)
It didn't feel right to have a "DHCPClient" in a "Servers" directory.
Rename this to Services to better reflect the type of programs we'll
be putting in there.
In the TreeView, the background of the selected line (or any background,
really) was only drawn until the frame's width. When the text was larger
than the frame's width, this caused the end of the text to be displayed
without background, making it unreadable if it was white (which is the
default text color for selected lines).
To compute the background width, we have a choice between :
- The inner frame width (the current behaviour which causes the issue)
- The total width of all columns (which causes the background to end
early if the columns don't cover the full width)
The new algorithm uses the biggest of the above values, which gives us
exactly what we want in all cases :^)
Fixes#2134
Adds fully functioning template literals. Because template literals
contain expressions, most of the work has to be done in the Lexer rather
than the Parser. And because of the complexity of template literals
(expressions, nesting, escapes, etc), the Lexer needs to have some
template-related state.
When entering a new template literal, a TemplateLiteralStart token is
emitted. When inside a literal, all text will be parsed up until a '${'
or '`' (or EOF, but that's a syntax error) is seen, and then a
TemplateLiteralExprStart token is emitted. At this point, the Lexer
proceeds as normal, however it keeps track of the number of opening
and closing curly braces it has seen in order to determine the close
of the expression. Once it finds a matching curly brace for the '${',
a TemplateLiteralExprEnd token is emitted and the state is updated
accordingly.
When the Lexer is inside of a template literal, but not an expression,
and sees a '`', this must be the closing grave: a TemplateLiteralEnd
token is emitted.
The state required to correctly parse template strings consists of a
vector (for nesting) of two pieces of information: whether or not we
are in a template expression (as opposed to a template string); and
the count of the number of unmatched open curly braces we have seen
(only applicable if the Lexer is currently in a template expression).
TODO: Add support for template literal newlines in the JS REPL (this will
cause a syntax error currently):
> `foo
> bar`
'foo
bar'
Well, technically the initial sort order is 'ascending inode'.
However, that is unpredictable for the user.
In the rare case it is desired, it can be re-enabled by revealing the
inode column, and then sorting by it, in the TableView.
