GitLab

The goal here is to move to a JIT backed PCRE2 implementation, however
this just gets an initial port in place to use PCRE2 for this code. We can
eventually move other parts of GtkSourceView over to this implementation
as well depending on how complete we need to be.

This creates an ImplRegex intermediate structure that we can use to switch
the implementation from GRegex into PCRE2. Doing so will not only be
faster, but also allow us to eventually migrate to using a JIT for the
regex implementation as well as avoid deprecations from GRegex in future
releases of GLib.

Other modules will eventually need to be ported to this, but focusing on
GtkSourceRegex would result in the largest gain from language specs.

Just for convenience to open new files that may error on specific
conditions.

By providing a Flatpak manifest, we can start using Builder for
development so that things are easier for new contributors.

This also uses Sysprof for profiler integration so that we can
do performance testing from various subsystems during
development.

If -Dinstall_tests=true then we will now install the test-widget
application as gtksourceview5-test. This can be useful primarily
in developer situations like using Flatpak as a build
environment for testing but also for conformance testing on
something like GNOME OS images.

This uses the sysprof collector interface for both debug and profiling
when we detect we are being monitored by sysprof. This ensures that we
get all of our profiling data in one place (since we will want profiling
information from GTK itself side-by-side).

This is useful when doing development so that we get extra checking from
projects using GtkSourceView for nightly builds.

This will allow us to do profiling with sysprof-capture-4's collector
interface just like GTK does.

These are still a work-in-progress, but I'd like to see these shipped with
5.x and backported to 4-8 branch eventually.

These were supposed to be removed when porting.

GTK 4 port of GtkSourceView

See merge request !165

If we can detect no changes, then try to avoid all the resizing.

This allows the tooltip to shrink back to it's smallest size rather than
being pinned to the largest size.

We don't want to match everything when searching for these snippets.

This makes the INFO style more of a default type thing (which it is meant
for).

Long term we still need to handle translations for these, but this gets
things started.