Go syntax highlighting in Markdown code block

[dgrisham]

Type: Bug

Severity: Low

Version: Not sure how to get the version via CLI, but whichever is in the AUR https://aur.archlinux.org/packages/kakoune-git. I just updated, but the issue was there prior to the update as well (and the last time I updated kakoune was at least a month ago).

Description

When writing a go code block in a markdown file, e.g.

```go
func f() { /* ... */ }
```

The entire code block, including the leading ```go and trailing ```, are treated as one big string literal (which start and end with backticks) which means everything is just a single color. My guess is that the issue is with the markdown.kak file rather than go.kak, since the highlighting inside a code block shouldn't be affected by the characters defining the block itself.

Edit Also note that the following modification, putting a ` after go fixes the highlighting inside the block (which isn't a solution, of course, but helps identify the issue):

```go`
func f() { /* ... */ }
```

Edit 2 Lot of backticks here, editing the formatting for clarity. Also, I suppose it likely isn't treating it as 'one big string literal', rather the first two backticks make an empty string literal, then the next backtick starts another, which is then closed by the first backtick in the closing ```, and finally the last two backticks in the closing trio make another empty string literal.

[dgrisham]

I tried to make a hacky-ish solution based on my very primitive understanding of how highlighters work by editing this line from:

  go         ```\h*go         ```          '' \

to

  go         (?<=```\h*go)         ```          '' \

or even

  go         (?<=```go)$         ```          '' \

but no variation on these seem to work.

[mawww]

@dgrisham I suspect

go ```\h*go\K    ```    ''

Will do the trick, you cannot use \h* in a lookaround with Kakoune's regex impl. I am wondering if the regex solution is good enough, or if we want to have another way to specify that the matched regex should not be taken as part of the region itself.

[dgrisham]

@mawww Nice, that (+ the other changes @danr made) work for me. Thanks! And yeah, it seems like it could be quite clean to be able to specify a region by either included or excluded boundaries -- especially since that might also take care of the comprehensive negative lookbehind that is needed at the moment, unless there's another way around that.