`Directory::path()` returning `ErrorOr` makes it awkward to use, and all
current users create a Directory with a path. If we find we need
pathless directories later, we can come up with a clever solution
then. :^)
This also removes DirIterator::error_string(), since the same strerror()
string will be included when you print the Error itself. Except in `ls`
which is still using fprintf() for now.
Our `find` utility makes use of the `dirent::d_type` field for filtering
results, which `Core::DirIterator` didn't expose. So, now it does. :^)
We now store the name and type of the entry as the "next" value instead
of just the name. The type is exposed as a `DirectoryEntry::Type`
instead of a `DT_FOO` constant, so that we're not tied to posixy
systems, and because proper enums are nice. :^)
This widget originally used text, but at the time we did not support
painting multi-code point emoji as text at all. So it was changed to
paint emoji with their bitmaps in commit 8190120f95.
Now that we can paint text with multi-code point emoji, revert this
widget to use text again. This has the added benefit that the dialog has
a what-you-see-is-what-you-get effect; any emoji with text presentation
in the font (e.g. U+00A9 Copyright) will be displayed as such in the
dialog, which is how the text would be painted when selected anyways.
Note that to accommodate some emoji sizes, this also had to bump the
button sizes a bit, otherwise they would be displayed with an ellipsis.
The EmojiInputDialog, for example, will want its toolbar buttons to have
a tooltip which differs from its text. If no tooltip override has been
provided, we fall back to the button text still.
This was preventing some unqualified emoji sequences from rendering
properly, such as the custom SerenityOS flag. We rendered the flag
correctly when given the fully qualified sequence:
U+1F3F3 U+FEOF U+200D U+1F41E
But were not detecting the unqualified sequence as an emoji when also
filtering for emoji-presentation sequences:
U+1F3F3 U+200D U+1F41E
The values aren't 100% self-consistent, but it probably doesn't make
a difference for u8 color data. Good enough for now. See all the links
on #17714 for some more background.
This creates folding regions for blocks defined by the following:
- if/elseif/else/endif
- foreach/endforeach
- while/endwhile
- macro/endmacro
- function/endfunction
Since there is no guarantee that each keyword will have a matching
partner, we do our best by looking for the most recent possible start
token matching the current end token. If we find one, we link to it and
drop all the other start-tokens that happened in between. For example,
we would define a folding region for this invalid file like so:
[-] if(TRUE)
│ while()
└─ endif()
This sorts the array of generated emoji data by code point (first by
code point length, then by code point value). This lets us use a binary
search to find emoji data, rather than the current linear search.
In a profile of scrolling around /home/anon/Documents/emoji.txt, this
reduces the runtime of Gfx::Emoji::emoji_for_code_points from 69.03% to
28.42%. Within that, Unicode::find_emoji_for_code_points reduces from
28.42% to just 1.95%.
Before of this patch, we looked at the unveil data of the FinalizerTask,
which naturally doesn't have any unveil restrictions, therefore allowing
an unveil bypass for a process that enabled performance coredumps.
To ensure we always check the dumped process unveil data, an option to
pass a Process& has been added to a couple of methods in the class of
VirtualFileSystem.
