Created attachment 23557 [details]
script demostrating the hiliter failure

On Wednesday 13 February 2008, Pino Toscano wrote:

I'm afraid I haven't followed the development of perl much recently. I assume 
this is an operator along all other operators? I'll add it as soon as you 
confirm.

Yes, this is an ordinary operator. Comes in two flavors:

// which is ordinary binary 'defined-or' operator
    $a = $b // 'BOGUS'; # $a becomes $b if defined($b), 'BOGUS' otherwise

and

//= which is assignment version of it
    $a //= 'BOGUS'; # $a becomes 'BOGUS' unless already defined

Created attachment 32053 [details]
Some ameture attempts at getting // working 

This a half assed attempt at getting a handful of the perl5.10 changes in.

its mostly relying on the assumption that / style regex are not entirely practical in most locations when its not prefixed by either  =~ or !~ so it searches for the ~ /   pattern instead of just  / ( which it presently uses ).

Hi Kent,
/PATTERN/ can be used as a statement about everywhere in perl, and quite often is. /match/ or die;)

Therefor we need to find a better way. The order in which things are done in the xml file is absolutely not random, and moving this particular test (the one that you removes) is likely to cause trouble.

Could you try instead of removing it to make it test for "/(?!/)" instead, to make it not match "//"?

I tried that the first time, strangely for some reason it doesn't work at all. 

Neither Of these work:

<RegExpr attribute="Operator" context="pattern_slash" String="/(?:[^/])" beginRegion="Pattern" /> 
<RegExpr attribute="Operator" context="pattern_slash" String="/(?!/)" beginRegion="Pattern" /> 
<RegExpr attribute="Operator" context="pattern_slash" String="/[^/]" beginRegion="Pattern" /> 

I really don't get how this syntax highlighter works, XML oriented programming totally eludes me.

whats really confusing me is why

 $foo  /  $bar ; # is not interpreted as regex 

but 

 $foo / / $bar; # is.

And the *strangest* thing is that it the regex starts with / and runs into bar, not runs from the first / 

Highlighter still thinks the first / and things after it are plain text.

and stranger still 

 $foo  /bar/ $bar # is interpreted as being totally devoid of regex. 

And I can't see any rules in the file that would do that.

Hi Kent,
I have to find some time to look closer into this then, thank you for trying and letting me know!

One of the problems with the regexps in the highlight processor is that qregexp isn't as good as the perl one.

Hi guys,

This bug hasn't seen any attention in a while, but is quite critical for those of us who love perl and kate.  Currently any use of the defined-or operator causes the remainder of the document to be highlighted as a regex!  My current solution has been to disable highlighting of /$regex/ entirely, however a proper fix for perl 5.10 highlighting would be far superior and greatly appreciated.

Thanks,
Andrew

neither me, dhaumann or cullmann know/use perl, so we don't feel comfortable doing this ourselves. the best would be if one of you perl users could take another look at this. the syntax file is located at /usr/share/kde4/apps/katepart/syntax/perl.xml (or thereabouts). documentation for how these syntax files work can be found at http://kate-editor.org/article/writing_a_kate_highlighting_xml_file

if you have any questions about the highlighting stuff, please send an email to the kwrite-devel list, and we will try to help. :-)

I will take care of this tomorrow

Anders

Erlend Hamberg skrev:
> https://bugs.kde.org/show_bug.cgi?id=157773
> 
> 
> 
> 
> 
> --- Comment #10 from Erlend Hamberg <ehamberg gmail com>  2010-02-17
> 15:00:08 --- neither me, dhaumann or cullmann know/use perl, so we don't
> feel comfortable doing this ourselves. the best would be if one of you
> perl users could take another look at this. the syntax file is located at
> /usr/share/kde4/apps/katepart/syntax/perl.xml (or thereabouts).
> documentation for how these syntax files work can be found at
> http://kate-editor.org/article/writing_a_kate_highlighting_xml_file
> 
> if you have any questions about the highlighting stuff, please send an
> email to the kwrite-devel list, and we will try to help. :-)

SVN commit 1092079 by alund:

Check for operator // before checking for /
I have only checked a little, please check!

BUG: 157773


 M  +5 -3      perl.xml  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1092079

Hi Anders,

Thanks for working on this, I've given it some testing and it seems that highlighting is still broken in the following cases, ie. when the 'defined-or' operator is preceded by a closing bracket of any sort.

sub test { return undef }
my $test1 = test() //= ':(';

my %hash = (a => 1, b => 2, c => 3);
my $test2 = $hash{d} //= ':(';

my @array = ('a', 'b', 'c');
my $test3 = $array[3] //= ':(';

Cheers,
Andrew

Thanks for testing! I believe I know why, so I will attempt a fix tomorrow 
(CET)

If it's any assistance, the following change to the highlighting XML disables bare regex (/$regex/ as opposed to m/$regex/ or s/$regex/$replace/), but allows me to use defined-or operators without them triggering regex highlighting.

Perhaps this is a clue as to where the issue lies?

--- perl.xml    2010-02-19 00:10:36 +0000
+++ perl.xml    2010-02-19 00:09:43 +0000
@@ -377,7 +377,7 @@

         <RegExpr attribute="Normal Text" context="#stay" String="[\w_]+\s*/"
/>
         <RegExpr attribute="Normal Text" context="#stay"
String="[&lt;&gt;&quot;':]/" />
-        <DetectChar attribute="Operator" context="pattern_slash" char="/"
beginRegion="Pattern" />
+        <!--<DetectChar attribute="Operator" context="pattern_slash" char="/"
beginRegion="Pattern" />-->
         <RegExpr attribute="Operator" context="#stay"
String="-[rwxoRWXOeszfdlpSbctugkTBMAC]" />

         <DetectChar attribute="Normal Text" context="#stay" char="{"
beginRegion="Block" />

It seems there's also now been a regression in the perl syntax highlighting.

my $value = $object->method unless test();

Is no longer highlighted the same as:

my $value = $object->method() unless test();

Not completely fixed yet, but we are working on it :)

Andrew Whatson skrev:
> Perhaps this is a clue as to where the issue lies?

Well, I would prefer to keep support for those patterns if possible, as they 
are very common. And I believe I can, I'm just a bit rusty ;)

SVN commit 1092536 by alund:

More defined-or fixing, various tests from Andrew now pass, and anonymous patterns work :-)
CCBUG:157773


 M  +7 -8      perl.xml  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1092536

Hi Anders,

This is looking really good, it appears that you've fixed the original issue perfectly.  I'll have a more detailed look through my codebase on Monday just to be sure.

There is still the issue with the following example, which as far as I can see was introduced since the recent activity on this bug.

my $value = $object->method() unless test(); # is highlighted correctly
my $value = $object->method unless test();   # should appear the same,
                                             # but doesn't!

This seems to occur for any code following a bare dereference.

Regards,
Andrew

Hi, what's the state of this in KDE >= 4.6?
Since I'm not a perl expert, can someone give a quick summary about this report, and whether the initial issue is fixed?

The report is getting pretty long, so it's hard to quickly grasp what this is about.

All issues mentioned in this bug look fixed to me, testing with 4.7.0.

Ok, thanks a lot, Andrew. If there are other issues, please open new reports.