We have a custom RC file defining various styles we need, and we want
the user to be able to override them (e.g. if they want -- or need --
other colors). Fair enough, one would simply call gtk_rc_parse() with
the appropriate filename. However, the styling rules applies in the
order they are loaded, then if we load our styles after GTK has loaded
the user's ones we'd override them.
There are 2 solutions to fix this:
1) set our styles' priority to something with lower than "user"
(actually "theme" priority because rules precedence are first
calculated depending on the priority no matter of how precise the
rules is, so we need to override the theme).
2) prepend our custom style to GTK's list while keeping priority to
user (which is the default), so it gets loaded before real user's
ones and so gets overridden by them.
One would normally go for 1 because it's ways simpler and requires less
code: you just have to add the priorities to your styles, which is a
matter of adding a few ":theme" in the RC file. However, KDE being a
bitch it doesn't set the gtk-theme-name but rather directly includes
the style to use in a user gtkrc file, which makes the theme have
"user" priority, hence overriding our styles. So, we cannot set
priorities in the RC file if we want to support running under KDE,
which pretty much leave us with no choice but to go with solution 2,
which unfortunately requires writing ugly code since GTK don't have a
gtk_rc_prepend_default_file() function. Thank you very much KDE.
Though, as a side benefit it also makes the code work with people using
gtk-chtheme, which also found it funny to include the theme in the user
RC file.
The code used a Scintilla-specific regex escape (\<) which doesn't work
anymore since the time we switched to full PCRE (which uses \b). So,
update the regular expression to PCRE.
Also, properly escape the name to search in the unlikely case it has
regular expression escapes in it; and properly check for word
boundaries even when not searching with an extension.
If current position is not at selection start (e.g. bottom-up
selection), editor_get_filetype_at_current_pos() will start returning
improper result as soon as the first buffer change since the style at
the actual current position will have been invalidated and not yet
recomputed.
If we provide an AccelGroup when creating a menu item using a sock ID,
it installs the GTK default accelerator, accelerator we can't remove
since we don't know about it. So, don't give an AccelGroup so GTK
don't install it's own accelerator.
This fix also required to properly update the accelerator on some item
we used to ignore since the update didn't work anyway (since the GTK
accelerator was displayed instead).
Note that this doesn't fix the fact the editor popup menu accelerators
are never updated after startup so they don't get updated before
restart after changing a keybinding in the preferences. This is a
separate (and less problematic) issue due to a simple lack of update.
Closes#1912683 and #3599251.
Previously was hard coded with options to suit xterm. As this is
being replaced with different terminal programs some do not accept
the same options. The new setting stores the whole command with
%c to substitute the script name. Upgrades old settings if a new
one does not exist.
This allows for users to change the colors if needed (may be useful
with some themes or color blind persons).
On the sidebar, only the color is applied for now. This is because
it is not possible to style cell renderers through RC files, all having
to be done in the code; so currently only the color is applied.
A preference for an icon doesn't make sense; if someone don't like
her theme's icon she should either switch to another theme, override
that specific icon or don't bother.
This reverts commit 6897cd49c69535c6563e56ae011c6f8382fec485.
When performing a regular expression search on a range, and there is a
match past the end of the range, search_find_text() used to improperly
return the position of the match, but without filling the
Sci_TextToFind structure. This lead to the calling code assume there
was a match, and maybe read the uninitialized fields in the
Sci_TextToFind structure, thus leading to undefined behavior.
So, fix search_find_text() so it properly returns -1 when there is a
match but it is outside the bounds.
When pasting with the X primary clipboard (middle mouse button), the
user expects the focus to be grabbed by the widget receiving the data.
No idea why the VTE itself don't grab upon middle click, though.
Getting the statusbar context ID using the context registration API
allows for other (namely, plugins) to register their own context
without a risk of overriding Geany's one.
