Instead of hand-parsing the argument list and possibly choking inside
comments, strings, heredoc, etc., use the normal token mechanism and
simply convert the tokens to a string representation as the argument
list. This technique might perhaps lead to some missing characters in
the argument list representation in the (unlikely) case a token
appearing in the argument list is reported as a generic type for which
it is impossible to know the correct string representation, but this
could always be fixed by adding a specific token type and is anyway
less problematic than maybe breaking further parsing of the document.
PHP namespaces don't work anything like a block, so the implementation
is specific and not combined with scope management. Namespaces cannot
be nested, and they may apply either to the rest of the file (until the
next namespace declaration, if any) or to a specific block.
Namespaces applying to the rest of the file:
namespace Foo;
/* code in namespace Foo */
namespace Bar\Baz;
/* code in namespace Bar\Baz */
Namespaces applying to blocks:
namespace Foo {
/* code in namespace Foo */
}
namespace Bar\Baz {
/* code in namespace Bar\Baz */
}
namespace {
/* code in root namespace */
}
Only generate tags for variable declarations without assignments inside
classes and interfaces not to get fooled by rvalues.
This prevents generation of a "$bar" tag for something like:
$foo = $bar;
while still generating "$bar" tag for:
class Foo {
var $bar;
}
Fix parsing of functions declarations with a leading ampersand (&),
used to make the function return a reference:
function &foo($arg1, $arg2) {
/* ... */
}
Rewrite the PHP parser as a real parser, not using regexes. This is
more complex but allows for better parsing.
Visible changes:
* Scope reporting;
* Variables inside functions are no longer reported (this is a
deliberate choice, but can be easily changed);
* Only the PHP part is parsed (e.g. it doesn't report JavaScript
functions anymore);
* Function arguments spanning several lines are properly reported;
* Interfaces are not yet parsed.
Otherwise the new parser should behave like the old one, at least
where it used to be right. Parsing of more constructs and reporting
more details is planned.
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.
