It's now possible to give GTextEditor a vector of Span objects.
Spans currently tell the editor which color to use for each character
in the span. This can be used to implement syntax highlighting :^)
There were various little mistakes in the width calculations used by
the line-wrapping layout code.
With this patch, we should no longer see the horizontal scrollbar get
enabled with line-wrapping enabled. I will hide the scrollbar in a
separate patch.
text_position_at() was returning -1 if the position wasn't in
the bounds of a visual line. Now if the position is past the last
line, we simply return the last line index instead of -1.
Fixes#502.
When we update our content size, the width & height is now calculated
from the visual line rect size. Also now after we recompute all visual
lines, if the total height is different, we re-update the content size.
Compute the final file size and ftruncate() the destination file to the
right size immediately instead of incrementally appending to it.
This kind of optimization belongs in the kernel, but until we have it
there, this makes saving text files a whole lot faster. :^)
Pressing right did nothing when the very last characters of the buffer
were selected.
The expected action would be for the cursor to move to the end of the
buffer.
This patch fixes that.
Find_prev returned invalid when the contents of the file were equal to
the contents of the search box.
This is due to the checker walking on an empty character at the end of
a line.
To expand a bit on how the line-wrapping works, each physical line of
text is broken up into multiple visual lines. This is recomputed when
the document changes, or when the widget is resized.
Each GTextEditor::Line keeps track of the visual breaking points, and
also their visual rect in content coordinates. This allows us to do
painting and hit testing reasonably efficiently for now.
This code needs some cleanup, but it's finally in a working state, so
here it goes. :^)
This is not finished, but since the feature is controlled by a runtime
flag, the broken implementation should not affect users of this widget
too much (in theory :^).)
- GTextRange find(const StringView& needle, const GTextPosition& start)
This function searches for the needle in the haystack (the full text)
and returns a GTextRange for the closest match after "start".
If the needle is not found, it returns an invalid GTextRange.
If no "start" position is provided, the search begins at the head of
the text document. :^)
Thanks to Dan for pointing this out on IRC:
<danboid> I see TextEditor still numbers its lines from 0. You're too much of a programmer sometimes kling! :)
< kling> that might be the most extreme form of "programmer design" I've seen in serenity
Instead of computing the path length inside the syscall handler, let the
caller do that work. This allows us to implement to new variants of open()
and creat(), called open_with_path_length() and creat_with_path_length().
These are suitable for use with e.g StringView.
