Extract `split_line` function from `reflow_lines` to reimplement it in
the future without using SCI_SPLITLINES to achieve the
behaviour consistent with the "Line breaking" option.
* Unhardcode "pos" and "style" statusbar messages which were only
enabled when GEANY_DEBUG is defined and make them real possible
format chars.
* Move needless global "statusbar_template" into UIPrefs structure
with the other UI preferences, removing (now) pointless ui_finalize()
function.
* Rename "add_statusbar_statistics" to "create_statusbar_statistics"
and make it return a gchar* instead of passing in a GString argument
to update. Fixes a one-time "leak" of the GString and makes the code a
little easier to follow.
* Move the default statusbar template string to the top of the file
and use it as the default for the various preferences so the user has
something to base their customizations off of. TODO: check that the
N_() translations stuff works OK.
"regex_match_text" and "regex_matches" being globals, performing
several searches and then the replacements separately lead to them
having unexpected values, resulting in incorrect behavior and crash.
Fix this by removing the globals and instead make the search functions
return match details. Not only this fixes the issue, but also make the
code a lot more maintainable by not having globals introducing side
effects (proof of them being an issue is that c83a93e inadvertently
broke things bad).
Fix the selection start position after uncommenting if it was inside
the comment marker; and fix the selection end position if it was in
the indentation or before or inside the comment marker.
Improved fix for #3576431.
Instead of re-implementing the search-all algorithm everywhere it is
needed, move it to a re-usable function. This is useful because some
care is required to avoid improper rematches and endless loop, so
avoiding duplication is important (especially if something has to be
fixed someday).
Fix the search & replace algorithm to make sure a replacement won't
possibly affect the next one (e.g. in case of lookahead and lookbehind
regular expressions).
To do so, first find all occurrences and only then perform replacements,
instead of doing both together.
This fixes searching/replacing of any pattern that may be affected by
its replacement (e.g. patterns that look for something not a character
in the match range), including:
* Start/end of line:
Before this change, searching with regular expression "^A" and
replacing with an empty string on the input "AA" would have resulted
in an empty output ("^A" matching again after removing the first
one). Now it properly only removes the leading "A".
* Lookahead/lookbehind:
Pattern "(?<=a)b" with empty replacement and input "abb" would have
resulted in the output "a" instead of "ab".
* And more generally, many patterns matching non-characters like
positions or out-of-match characters.
The originally used SIGQUIT has problems:
1) see the deleted comment
2) some xterm alternatives ignore it, so they don't stop
Changed to SIGTERM which is the canonical "terminate" signal.
Removed associated unneeded ignore of SIGQUIT.
The last line doesn't have EOL characters, so computing
(line_length() - eol_length()) is wrong on the last line.
Instead, use (line_end_pos() - line_start_pos()) as suggests
Scintilla's documentation.
Closes PR#124
On GTK 2.16 GTK_WIDGET_[UN]SET_FLAGS resolves to a do-while construct which
raises a syntax error when embedded into a ? operator.
Also gtk_widget_get_visible() is only available since GTK 2.18, so add a fallback to
the old variant.
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.
