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>

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>

damn, it doesn’t work over line breaks. but it’s a good direction. much simpler.

I fixed this already, no?

*** This bug has been marked as a duplicate of bug 321859 ***

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

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)

Created attachment 81234 [details]
Updated testcase

Updated testcase with descriptions of expectations.

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.

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.

Question is whether this can be fixed so fine-grained at all?

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.