Follow-up Comment #1, bug #49818 (project gettext): 1) Fixed in e4796a6
2) I have to re-check the list. I had used the command "perldoc perlfunc" as the base for the qualification of keywords, and I think it is more complete than http://perldoc.perl.org/index-functions.html A handful of the items are operators ("if", "else", "and", ...) and are already handled. But there could be new ones that should be added. Then there a keywords like "break", which can oddly enough be used like a parameterless function call "break()". Others from the same group, for example "__FILE__" can only be used as such ("__FILE__()" is a syntax error). At first glance it looks like it makes sense to treat all of the "Non-function keywords" either as operators or functions for our purposes. I will go through the list one by one. It contains a lot of additions to the Perl language that are not yet handled by x-perl.c. At the end of the day, the parser actually does not care whether a certain symbol represents a function name, a keyword, an operator or whatever else. We are trying to disambiguate this case here: foo / bar / gm; One interpretations is a chained division: foo() / bar() / gm() The other one is an invocation of the function foo() with a regex/pattern match as its argument: foo(/ bar /gm) That can only be disambiguated at run-time, but knowing the prototypes of the builtin functions helps at least a little. _______________________________________________________ Reply to this item at: <http://savannah.gnu.org/bugs/?49818> _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/
