| 15 Nov 2025 |
Katie | MMMM... got it, yes, that is a problem | 18:45:37 |
Katie | maybe (/foo/).match | 18:45:50 |
Katie | or maybe a different bookend token | 18:46:10 |
Katie | |foo| | 18:46:18 |
antifuchs | Empty list is falsy in the originator of the meme, lisp (fixed in scheme though); still not sure I love it there | 18:46:21 |
aloisw | It's quite reasonable given how builtins.match semantics work. Unmatched capture groups give null, matched capture groups give the list of its submatches. | 18:46:31 |
aloisw | Same problem of being a footgun if the user leaves off the seemingly redundant parenthesis. | 18:47:00 |
Katie | Yeah, I don't love the parentheses idea | 18:47:24 |
aloisw | Like I don't see the point of syntactic sugar that makes an uncommon operation look slightly shorter at the cost of adding massive footguns. | 18:47:29 |
Katie | I don't know how convincing it will be to you, but I can try to offer my perspective there on the appeal for me | 18:48:38 |
Katie | I have... god only knows what kind of dyslexia-adjacent cognitive bullshit going on in addition to my really crappy vision. RegEx literals being their own unique semantic construct unto themselves that IDEs can differentiate and color/highlight as such is a HUGE benefit to me. I'm loathe to praise JavaScript for almost anything, but RE literals are a huge win for me there that I really miss when writing say, Rust. I find Nix Path Literals exceptionally ergonomic for very similar reasons. It just helps me see and understand much more clearly what I'm looking at, vs. just another string | 18:53:25 |
Katie |
| 18:54:10 |
Katie | * plus shorter is nice too | 18:54:16 |
Katie | at the risk of sounding naively optimistic, I imagine their must be some happy path to deliver the benefits sans footguns | 18:55:40 |
522 it/its ⛯ΘΔ | usage aware highlighting (if this is used inside a builtins.match / passed to something that takes a regex(not that nix really has a type system that'd make that easy to determine)) would also help that | 18:56:32 |
aloisw | I feel like highlighting the first argument of builtins.match will get you 90% of the way for the thing you have mentioned. | 18:56:33 |
522 it/its ⛯ΘΔ | without needing language changes | 18:56:36 |
522 it/its ⛯ΘΔ | treesitter can do some level of that (things passed to writeShellApplication are highlighted as bash) | 18:57:37 |
522 it/its ⛯ΘΔ |  Download image.png | 18:58:39 |
522 it/its ⛯ΘΔ | plus this to manually specify the language, though that's quite verbose for single line things | 18:58:56 |
Katie | this is true | 18:59:09 |
Katie | What I would give to at least be able to put that syntax comment inside the string (though I understand why that's not feasible) | 19:00:07 |
P | Katie: I'm totally in the same boat RE: there is a huge benefit in having syntax awareness for constructs like RE inside a string. For me the moment was when I used JetBrains stuff with Kubernetes Helm charts for the first time. Game changer. But like 522 it/its ⛯ΘΔ already said, luckily, tree sitter is pretty good at nesting our Syntaxes. 🎉🥳
Now we just have to ensure it recognizes that automatically every time in all relevant cases. How hard can that be 🫠
| 19:05:27 |
aloisw | One problem with adding stuff to the Nix language (whether regex literals or string distinguishers) is that the syntax is already extremely crowded due to questionable decisions of the past | 19:07:39 |
Katie | yeah... | 19:23:55 |
Katie | I do hear that | 19:23:59 |
tc424 (Steve D) | I for one welcome this first step on the road to merging nix and perl syntax | 20:35:33 |
antifuchs | if syntax highlighting is a concern, tree-sitter-nix can already recognize strings marked | 22:55:50 |
antifuchs | * if syntax highlighting is a concern, tree-sitter-nix can already recognize strings marked with /* bash */ and other markers... | 22:56:17 |
| 16 Nov 2025 |
KFears (burnt out) | In reply to @522_:catgirl.cloud treesitter can do some level of that (things passed to writeShellApplication are highlighted as bash) Damn, TIL | 00:22:54 |