Function symbols_get_context_separator() returns the symbol
separator for the language, but some languages do not have
symbol context separators, for example markup languages like
Asciidoc. To prevent the symbols pane wrongly detecting and
acting on a valid character sequence as a separator, return a
non-printing character which should not occur.
Options "" and NULL not used as they break some code and would
need an ABI bump.
Other languages can be added as they are identified.
When switching the current notebook tab, we need to take only visible
pages into account. If we don't and we try switching to an invisible
page, nothing happens.
In practice, the issue is visible on the message window notebook if one
of the tabs are hidden due to one of the "msgwin_*_visible" settings.
They used to be because their parent menu item (Editor) was
document-sensitive but now they are in the top of the View
menu they need to be invdividually made so.
TODO: should they really be/have been document-sensitive? They
can still change the pref without a document open and their
equivalent options in the Preferences dialog are not
document-sensitive? Same goes for existing "Change Font" item.
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.
