Keyword detected for tagged-union datas only absent any record-syntax

[metaleap]

Minor quirk really, but for the sake of completeness of open (non)"issues" 😁 In the screenshot below, observe:

• at the bottom --- correct detection of deriving in keyword scope in the tagged-union data QueryData that has no record-syntax, vs.

• at the top (and also in the data Query near the bottom) --- incorrect mis-detection of deriving in variable scope when record-syntax is present in the data

My RegEx is super-rusty, maybe I'll try my hand here later today, but wanted to report for now ;)

[JustusAdam]

This was actually an issue of how the end of a function definition is detected.
I added } as a potential end marker for a function signature definition, which fixed the problem. I didn't see it breaking anything else but im still not sure the current regex covers all cases.

[metaleap]

Cool, that fixed it! Here's another minor quirk, but just for fun or in case you're obsessed about regexing deeper and deeper 🤣

Observe deriving typeclasses get tagged as entity.other.inherited-class only when in parentheses, but GHC is lenient enough to allow a single one without those. Not sure about the actual official Haskell98 / Haskell2010 standards though..

Ah well, not a big deal anyway, everyone knows one cannot derive-from a data-constructor ^_^ so feel free to ignore

[metaleap]

Also I suppose one could make a case for type-constructors appearing inside/next-to a data-constructor to be tagged, but again I suspect in regexing this might be a can-of-worms.. then again, just because regexes confuse me, doesn't mean the same holds for others :P

[JustusAdam]

Regexes and me are a love/hate relationship 😂.
But writing the Regexes for these grammars is a nightmare, because they can't span multiple lines. If you want that you need to do some nightmarish begin-regex/end-regex stuff.

But I'll have a look at it maybe it's an easy one to fix.

[metaleap]

Yeah I imagine also Haskell's recursive and nested constructor possibilities are nightmarish to properly process in a regex even in a single line. Consider L62 above Between String String (1datacons, 2typecons) but it could be Foo (Maybe Bar) Int (ie: 1datacons (1datacons 1typecons) 1typecons) or Baz a (Either (Maybe String) b), crikey 😨

[metaleap]

Another fun little quirk for when you're in the mood: observe the 2nd module keyword, L2 in parens, seems to be tagged as a function (or maybe I need to better differentiate between different function.* tags? OK will investigate)

[JustusAdam]

There is a command in vscode (Show TM Scopes) which shows you exactly all the scopes the current syntax item is tagged with 😉 .

Btw its very nice of you to report these issues, but I'd much prefer if you weren't posting them in a closed issue.

It'd be better to open a new one. You could even open a new one for each one, that's much better because I doubt I'll get around to fixing all of them soon and then they might just get lost.

[JustusAdam]

The nested constructors are less of a problem, because its often unnecessary to pay any attention to the nesting. Just tag everything that starts with an upper case letter and is not a type signature as a constructor.

One thing which you may notice is that the data definitions are still wrong because the types of the fields are not tagged as types. Its correct if you use record syntax, because I can recognise the start of a type from the ::. But in index constructors its not. I haven't worked out yet how to correctly recognise the various parts of a data definition and how to detect where it ends. but perhaps this will happen at some point.

[metaleap]

You could even open a new one for each one

Ah cool, will do from now on. Some people don't wanna see "zig" new issues in their mailbox all at once come Monday, but yeah from a tracking PoV individual issues are better

[JustusAdam]

Oh I don't like being spammed either, but I'd rather have a full inbox than have all those issues be lost because no one remembers where they were reported.