so here's a fun one: https://github.com/leonoel/plop/blob/master/src/plop/gcc.cljc#L44 this one popped up as the only use of case with a (def) in it across testing a large sample of files. more than one editor colors the def as if it were a def form. not worth trying to handle perhaps? 🙂

actually, there was a second example, but it's from the same repository.

What's that (def) doing there?

curious about the general question of what to do about def-like forms within defmacro though.

it's part of the case.

so at https://clojuredocs.org/clojure.core/case, it would be a test-constant1

Ah, I see. But what is the result of evaluating it? I guess I have the same question about many of the cases there. I don't think I follow the syntax....

> The test-constants are not evaluated.

Mind blown: https://clojuredocs.org/clojure.core/case#example-5e53a6d2e4b087629b5a18a1

> not worth trying to handle perhaps? I predict it would be extremely hard to handle using tmLanguage grammar. And a real solution would probably involve macro expansion...

i'm not sure tree-sitter is going to fare any better here 🙂

We can handle this particular case (hehe) in Calva Highlight, if we choose to. It could serve an educational purpose to see that those are constants, but there are so many things we could do with our time! 😃

yes, good point. i think it's good to enumerate (and briefly look at each point), but need to consider what things to focus on in the context of what else there is.

You are collecting material for a super interesting series of blog posts, me thinks.

lol, i am collecting for sure.

i'm getting Error: invalid pattern in look-behind for:

'match': '(?<=(^|\\s|\\(|\\[|\\{))(true|false)(?=(\\s|,|\\)|\\]|\\}|\\^|$))'

'true'.match(/(?<=(^|\s|\(|\[|\{))(true|false)(?=(\s|,|\)|\]|\}|\^|$))/)

ah, here it is (for look-behinds...):

different character length is allowed in top level alternatives only.

'match': '(?<=^|\\s|\\(|\\[|\\{)(true|false)(?=(\\s|,|\\)|\\]|\\}|\\^|$))'

(til, first-mate uses oniguruma for tm grammars -- i guess it shouldn't be a problem in vscode because of what's mentioned here: https://code.visualstudio.com/api/language-extensions/syntax-highlight-guide#textmate-grammars)

Calva sometimes prints sudden newlines within pprint output. When I build an uberjar and run the same thing in console, the same issue is not there.

This might be a REPL thing as well, don't know.

@sogaiu To my experience it has depended on things what works in node or not. I think they have upgraded the regex capabilities in vscode lately by upgrading to a newer Electron. It's is actually a todo to investigate that and see if something can be won by making Calva require a newer version of VS Code.

thanks for the info!

iiuc, atom uses oniguruma only for textmate grammars. is it possible vscode does the same? the page linked above has the text: > TextMate grammars are a structured collection of Oniguruma regular expressions and are typically written as a plist or JSON. but i suppose that's not actually saying that vscode uses oniguruma...

I have always assumed it uses oniguruma. At least it uses something different than what vscode uses for the extension code's regex needs. I used to not be able to have things like \p{lL} in the extension, but I could add it to the tmLanguage grammar w/o complaints. (Now it seems \p works in the extension too, at least noone has complained since I added it to the token cursor's scanner.)

Also, the process for updating the tmLanguage grammar's of the vscode built-in grammars is that you first get your PR merged into the Atom repo, then tell the vscode team. Surely, it must mean that whatever regex engine Atom uses, vscode also uses, right? (Which begs the question: Does Atom use Oniguruma? But anyway 😄 )

BTW, it took me half a year to get any response on my PR to the Atom repo, which is why I moved things into Calva instead. Now that is merged there, but Calva's grammar has evolved quite a bit beyond, haha.

the info on oniguruma in atom i found was from: https://discuss.atom.io/t/regular-expression-lookaround-support-in-find/12400/2 -- ofc that's 6 years ago. off to sleep -- ttyl!