Fix comment rendering in function definitions

[JakubSchwenkbeck]

Problem:
Comments after function signatures were not highlighted properly, since the function parsing rule was consuming too much text.
Resolves #44

Fix:
Adjusted the end pattern in definitions to stop at //, allowing the comment rule to apply correctly.

Change:
Added the // chars to the end rule :

"end": "(?=//|\n)|(?<=\\S)\\s*(?==(?!>))"

Tested: Works after reloading VSCode with the examples:

Before:

With changes:

---

Now, // renders as an actual comment. ✨

[JakubSchwenkbeck]

I am wondering if there should be multi-line comments ( /* ... */) allowed at this place?

[jiribenes]

Is this correct? Won't this break something like:

def foo // my comment here
  (n: Int => String at {io})
  { prog: () => Unit } = prog()

EDIT: As a nitpick, it's best to test with syntactically valid code, the something doesn't seem to be syntactically okay 🔍 🕵️

[b-studios]

I am wondering if there should be multi-line comments ( /* ... */) allowed at this place?

We are deprecating them for /// anyways, so if at all, do support those.

[JakubSchwenkbeck]

I tested the current version like so:

Let me know if you have any edge cases in mind that might require additional testing!

[JakubSchwenkbeck]

I also thought about the solution of keeping the // out of the regex and implement a pattern for the comment line. This worked my tests aswell

 "definitions": {
  "patterns": [
    {
      "begin": "\\s*(extern)\\s+((?:(?:\\{[^\\}]*\\}|[a-zA-Z][a-z-A-Z0-9_$]*)\\s+)?)\\s*(def)\\s+([a-zA-Z][a-z-A-Z0-9_$]*)\\b",
      "end": "(?=\\n)|(?<=\\S)\\s*(?==(?!>))",
      "captures": {
        "1": { "name": "storage.modifier.extern.effekt" },
        "2": { "patterns": [{ "include": "#capabilities" }] },
        "3": { "name": "keyword.declaration.function.extern.effekt" },
        "4": { "name": "entity.name.function.effekt" }
      },
      "patterns": [
        { "include": "#parameters" },
        {
          "begin": "//",    <-- this is new
          "end": "$",
          "name": "comment.line.double-slash.effekt"
        }
      ]
    },

  

[jiribenes]

I tested the current version like so:

Let me know if you have any edge cases in mind that might require additional testing!

Sorry, I can't see how does this tests the highlighting of non-comment parts.
Specifically, the "patterns": [{ "include": "#parameters" }] part (everything that is a parameter between start and end of the pattern).
You can also use VSCode's debugging tools (Developer: Inspect Editor Tokens and Scopes) to see the assigned classes if your highlighting theme doesn't show them, though I'd highly recommend a theme like Dark+ that shows more of the colours for easier visual identification. :)

I also thought about the solution of keeping the // out of the regex and implement a pattern for the comment line. This worked my tests aswell
[...]

Couldn't we use just { "include": "#comments" } or something similar? That's akin to what the original issue suggested, I believe.

[JakubSchwenkbeck]

I wasn’t entirely sure if this is what you meant in your latest comment, but after testing, it looks like adding { "include": "#comments" } resolves the issue effectively.

Before the Change

After the Current Changes

With { "include": "#comments" }

This small addition seems to be the correct approach. Let me know if this aligns with what you had in mind!:)