Vte.Regex.new_from_match keep warning with:
(guake:29728): Vte-WARNING **: 19:36:56.760: (vtegtk.cc:1964):int
vte_terminal_match_add_regex(VteTerminal*, VteRegex*, guint32): runtime check failed:
(_vte_regex_get_compile_flags(regex) & PCRE2_MULTILINE)
In Vte source code, it will check the flags have contain PCRE2_MULTILINE:
g_warn_if_fail(_vte_regex_get_compile_flags(regex) & PCRE2_MULTILINE);
But, Vte nor GLib didn't provide the MULTILINE flag value:
GLib.RegexCompileFlags.MULTILINE = 2
Vte.REGEX_FLAGS_DEFAULT = 0x40180000
Vte source code in vte/bindings/vala/app.vala give out the value
flags = 0x40080400u /* PCRE2_UTF | PCRE2_NO_UTF_CHECK | PCRE2_MULTILINE */;
from Vte commit list, we can found that PCRE2_MULTILINE value is 0x400:
(https://mail.gnome.org/archives/commits-list/2016-September/msg06218.html)
flags |= 0x00000400u; /* PCRE2_MULTILINE */
Fix it with providing 0x40080400u as flag value
If we don't block notebook button-press-event, it will affect search box,
when double click on search box button or search entry, it will then add
a new page with focus, which is what we don't want.
So, block this event when search box is visible, and unblock it when
search box is show off.
User can search their terminal by search box. Search is based on vte.
Default accel-key is CTRL+SHIFT-F, it will then show up a search box
at right bottom of the page. User can search by hitting Return to search
next, or hitting Return with Shift to search previous, or using next/prev
button to search.
ESC or anyother focus-out of search entry will hide the search box.
NOTE: it will only search on last focus terminal if the terminal has been
split out.
$ guake --save-preferences prefs.guake
$ guake --restore-preferences prefs.guake
**WARNING**
User will need to ensure the content inside the preferences file,
otherwise it may broke up the preferences, e.g. bad accel-key binding
In vte 0.52, a new option was added to emit only bold when bold text is
emitted, and made the default behavior in vte 0.56. For details, see
https://bugzilla.gnome.org/show_bug.cgi?id=762247
The motivation for the change is to allow better 256-bit color in applications
and colorschemes. However, traditionally, applications assumed that bold text
would also be bright, and many applications look quite bad with this setting.
It is therefore useful to allow users to decide whether to utilize this
behavior.
Fixes#1507Closes#1089
