Bug 322577

Summary: Javascript highlighting broken: object members not detected correctly
Product: [Applications] kate Reporter: Philipp A. <flying-sheep>
Component: syntaxAssignee: KWrite Developers <kwrite-bugs-null>
Status: RESOLVED INTENTIONAL    
Severity: normal CC: cullmann
Priority: LO    
Version: Git   
Target Milestone: ---   
Platform: Compiled Sources   
OS: All   
Latest Commit: Version Fixed In:
Attachments: Test case
Updated testcase
js highlighting bugs

Description Philipp A. 2013-07-19 15:51:47 UTC
consider following valid javascript (little-known fact: semicolons are truly optional in javascript):

var a = foo.bar
var b = baz

this colors the second line like “bar”

Reproducible: Always
Comment 1 Philipp A. 2013-07-19 16:11:43 UTC
i think i got it, care to test?

use the following block in javascript.xml instead of the current <context name="Object Member"/>

      <context attribute="Normal Text" lineEndContext="#stay" fallthrough="true" fallthroughContext="#pop" name="Object Member">
        <RegExpr attribute="Objects" context="#stay" String="(\s*\.\s*[a-zA-Z_$][\w$]*(?=\s*\.))+" />
        <RegExpr attribute="Object Member" String="\s*\.\s*[a-zA-Z_$][\w$]*(?!\s*\.)" />
      </context>
Comment 2 Philipp A. 2013-07-19 16:14:32 UTC
agh, sorry for the spam, but even better:

      <context attribute="Normal Text" lineEndContext="#stay" fallthrough="true" fallthroughContext="#pop" name="Object Member">
        <RegExpr attribute="Objects" context="#stay" String="\s*\.\s*[a-zA-Z_$][\w$]*(?=\s*\.)" />
        <RegExpr attribute="Object Member" context="#pop" String="\s*\.\s*[a-zA-Z_$][\w$]*(?!\s*\.)" />
      </context>
Comment 3 Philipp A. 2013-07-19 16:16:33 UTC
damn, it doesn’t work over line breaks. but it’s a good direction. much simpler.
Comment 4 Milian Wolff 2013-07-20 11:05:18 UTC
I fixed this already, no?

*** This bug has been marked as a duplicate of bug 321859 ***
Comment 5 Philipp A. 2013-07-20 11:18:48 UTC
Created attachment 81215 [details]
Test case

nope, you didn't. you fixed that other bug while reverting my attempt to fix this one.

this bug is about the following being wrongly highlighted:

a.b
var c = d

the other bug is about that being wrongly highlighted:

a.b / c

my code fixed the first and broke the second, yours the other way round. there’s still no code fixing both while also allowing object members being on different lines
Comment 6 Philipp A. 2013-07-20 11:29:35 UTC
oh, and there’s another thing: people usually use semicolons in javascript because the following code does unexpected things:

var a = b

(function someClosure() {
    ... 
})()

this tries to call “b” with the “someClosure” as its argument, and if that works, it tries to call the result value with no arguments: b(someClosure)()

our highlighting should help the user and highlight b as function call in that case (which worked some time before, i think)
Comment 7 Philipp A. 2013-07-21 09:10:42 UTC
Created attachment 81234 [details]
Updated testcase

Updated testcase with descriptions of expectations.
Comment 8 Milian Wolff 2013-07-21 15:32:40 UTC
Created attachment 81243 [details]
js highlighting bugs

well, as you can see both things you listed initially work just fine for me now. The more esoteric features below don't work though. Feel free to come up with proper fixes but it might be hard without a real parser.
Comment 9 Philipp A. 2013-07-21 17:16:53 UTC
you’re right about the two working. i thought you had just reverted my commit, which would have broken the first again. but you seem to have changed something else and fixed both. thanks.

i wouldn’t call 3a esoteric, though: it’s very common in jquery to do

foo
    .foo()
    .bar()
    .baz();

which should yield a highlighted “foo”.

3b is less common, but also not unheard of. i’ve never seen 3c, so it’s esoteric indeed, but it should work automatically if we get 3a and 3b to work.

4 would just be a nice help, but of course leaving out semicolons generally is a rare choice.
Comment 10 Dominik Haumann 2013-08-15 12:33:28 UTC
Question is whether this can be fixed so fine-grained at all?
Comment 11 Christoph Cullmann 2014-09-23 18:32:24 UTC
Each HL is only a heuristic, if you have a patch, to improve it, fine, else this is a wontfix, we need no bugs for such things. If you agree to some LGPL or similar for your example, we could add it to the regression tests for syntax hl, then we have it for later use if somebody improves it.