When we are showing symbol info for a macro or a function
in a c file, then add a link to search the source code
of that macro/function in codesearch.debian.net .

It uses the codesearch.debian.net regex search with the
following regex which looks up source definitions for C
macros and functions:

(?mi:^(?:#define\s+)?func_name)\s*\((?m:([^;]+)$)

This is more geared towards adwaita-3-32 branch.

This simplifies things for addins to only disconnect state in one place.

*_ref return value is (transfer full)
(in) parameters are defaulted to (transfer none)

https://wiki.gnome.org/Projects/GObjectIntrospection/Annotations

#736

This fixes #737

Signed-off-by: Nicholas Harvey <727-FrostyPenguin@users.noreply.gitlab.gnome.org>

This better matches the new headerbar colors

Without this patch, I see Builder output on the CLI:

cat: /proc/sys/fs/binfmt_misc/qemu-aarch64: No such file or directory
cat: /proc/sys/fs/binfmt_misc/qemu-arm: No such file or directory

This matches the dark style better for what is in gnome-3-24 HEAD.

https://en.wiktionary.org/wiki/momentarily#Usage_notes says:

> Many speakers object to the use of momentarily in the sense of “in a
> moment” rather than “for a moment”, since this is inconsistent with
> the meaning of momentary […]. In place of momentarily, many speakers
> prefer […] the phrase “in a moment”.

This ensures that we update the occurrance count when focusing the search
entry.

#724

Carmen Bianca Bakker authored Nov 17, 2018 and Administrator committed Nov 17, 2018

(cherry picked from commit ae3abc07)

Due to this error, the block was invisible in the generated doc:

diagnostics.rst:46: WARNING: Error in "code-block" directive

Themes can be reloaded during runtime as plugins are loaded, so you can't
just use the current theme to register actions. They need to be loaded
into the internal "base-layer" theme to be persistent.

Many of the later mockups had this, after we had already written the
initial widget.

This allows for new/moved files to be searched, as long as they don't
match the .gitignore files.

This helps fix a situation where removing a GtkStack child focuses the
wrong "next view". That can be rather jarring when quickly moving between
files.

This is handy for users of vim that are used to being able to open a
directory and get a list of files. You can quickly type-ahead search and
press enter to open the target file.

We want to give some information about the location, being filename + line
number, so this is more descriptive.

Related #229

We do lots of tricky stuff in there, so we need to be a bit more precise
than other applications.

Some changes occurred recently, which make supporting this rather pesky.
However, this gets stuff building again. We have to rely on 3.28 instead
of 3.30 because of the freedesktop SDK extension. That has too old of
meson, so we need to install our own meson of 0.48.1.

Fixes #683

We want the button insensitive until there are results to display.

This plugin provides a grep backend that can optionally use git-grep when
the current project is using Git.

You can search for files from the project-tree by selecting "Find in Files".
That will limit the search results to the directory that has been selected.

If the selected node is a File (instead of a directory), then only results
from that file will be shown.

You can search using regular expressions supported by the particular grep
implementation. We don't currently guarantee options here (or validate them
for correctness). Some effort could be done here using GRegex in the future.

As we already have support for performing edits across a number of files in
the background, the grep plugin allows you to select matches and replace them
with new text. In the future we could extend this to try to preserve casing
of the replacement.

To avoid lots of small strings and numerous copies of them, a custom
GtkTreeModel was used. Instead we have a single large buffer of results that
were obtained from grep, and keep an index to the start of each line in the
buffer. A \0 replaces the \n that we received from grep.

I expect additional work will be needed here, but this seems like a reasonable
first attempt at the feature. Larger projects may need additional performance
tweaks.

This allows adding a command that will get the path of the selected item.