Newest at the top
| 2025-11-19 13:07:13 +0100 | trickard_ | trickard |
| 2025-11-19 13:04:35 +0100 | <yin> | ah, yes |
| 2025-11-19 13:04:29 +0100 | Inline | (~inlinE@2001-4dd7-ae97-0-4674-ae6d-2607-c022.ipv6dyn.netcologne.de) (Remote host closed the connection) |
| 2025-11-19 12:57:45 +0100 | <__monty__> | No, just talking about the highlighting here. Identifiers are green in definitions but pure, speed and duration are white? The latter at least also have a signature but coloring identifiers a different color in signatures is also weird to me. For types and constructors the distinction makes sense but not for other identifiers. |
| 2025-11-19 12:55:46 +0100 | srazkvt | (~sarah@user/srazkvt) srazkvt |
| 2025-11-19 12:54:44 +0100 | califax | (~califax@user/califx) califx |
| 2025-11-19 12:53:59 +0100 | <yin> | i'm just starting out trying to understand the basics of FRP |
| 2025-11-19 12:53:17 +0100 | <yin> | __monty__: is the definition of `pure` wrong? |
| 2025-11-19 12:52:27 +0100 | <yin> | jreicher: ok thanks |
| 2025-11-19 12:52:25 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2025-11-19 12:51:38 +0100 | <jreicher> | It's possible there's a bug in the parse, but I think that would be less likely. I am guessing though. |
| 2025-11-19 12:50:46 +0100 | <yin> | i'm checking other files and i think it has actually got much better than what i remember. but this specific bug is very noticeable on every file i'm checking. i can't find a pattern, it seems to randomly highlight some function names in signatures differently |
| 2025-11-19 12:50:46 +0100 | <jreicher> | yin: you might want to ask on #neovim. What you are seeing could be specific to the integration with treesitter, rather than treesitter itself, as treesitter doesn't actually do any highlighting; it just provides parsing information. |
| 2025-11-19 12:50:35 +0100 | jjhoo | (~jahakala@user/jjhoo) jjhoo |
| 2025-11-19 12:49:36 +0100 | <__monty__> | And speed and duration. |
| 2025-11-19 12:49:25 +0100 | gmg | (~user@user/gehmehgeh) gehmehgeh |
| 2025-11-19 12:49:17 +0100 | <__monty__> | Also the definition of `pure` though. |
| 2025-11-19 12:49:01 +0100 | <__monty__> | I'm actually more confused about the different coloring for identifiers in the other signatures. |
| 2025-11-19 12:48:42 +0100 | gmg | (~user@user/gehmehgeh) (Remote host closed the connection) |
| 2025-11-19 12:45:39 +0100 | <jreicher> | Oh! I'm so sorry, I shouldn't have assumed you were using Emacs. |
| 2025-11-19 12:45:01 +0100 | <yin> | it's nvim v0.11.5. not sure how to check the grammar version |
| 2025-11-19 12:39:56 +0100 | <jreicher> | Oh I think I see what you mean. Hmm. That might be a bug. What version of the treesitter grammar are you using? And also what version of Emacs? |
| 2025-11-19 12:37:39 +0100 | <yin> | it gets worse on more complex syntax. this was what i had in front of me. how do we explain the highlighting of `constant` in the signature? |
| 2025-11-19 12:37:16 +0100 | deptype | (~deptype@2406:b400:3a:9d2f:75a6:1ebe:81f5:e9d6) (Ping timeout: 264 seconds) |
| 2025-11-19 12:36:53 +0100 | <jreicher> | There's also even more fine grained control if you want. |
| 2025-11-19 12:35:16 +0100 | vardhan | (~vardhan@122.172.81.68) |
| 2025-11-19 12:35:06 +0100 | <jreicher> | Set `treesit-font-lock-level' to a smaller number |
| 2025-11-19 12:34:39 +0100 | deptype_ | (~deptype@124.123.133.153) |
| 2025-11-19 12:34:38 +0100 | <jreicher> | Why do you think it's inconsistent? It's giving you more grammatical information, which is why it looks different. You can set it to give less if you want. |
| 2025-11-19 12:33:55 +0100 | vardhan | (~vardhan@122.172.85.143) (Ping timeout: 264 seconds) |
| 2025-11-19 12:33:30 +0100 | srazkvt | (~sarah@user/srazkvt) (Read error: Connection reset by peer) |
| 2025-11-19 12:33:13 +0100 | <yin> | former is very inconsistent, even for trivial syntax like this |
| 2025-11-19 12:32:43 +0100 | <yin> | jreicher: tree-sitter highlight enabled: https://shot.jrvieira.com/1763551807.png vs disabled: https://shot.jrvieira.com/1763551862.png |
| 2025-11-19 12:23:55 +0100 | vardhan | (~vardhan@122.172.85.143) |
| 2025-11-19 12:22:13 +0100 | vardhan | (~vardhan@122.172.80.248) (Ping timeout: 264 seconds) |
| 2025-11-19 12:20:13 +0100 | deptype | (~deptype@2406:b400:3a:9d2f:75a6:1ebe:81f5:e9d6) |
| 2025-11-19 12:19:56 +0100 | deptype | (~deptype@2406:b400:3a:9d2f:445f:7a99:cca5:e330) (Remote host closed the connection) |
| 2025-11-19 12:16:40 +0100 | X-Scale | (~ARM@6.67.114.89.rev.vodafone.pt) X-Scale |
| 2025-11-19 12:13:49 +0100 | xff0x | (~xff0x@2405:6580:b080:900:a3f:66bc:6216:f05b) |
| 2025-11-19 12:13:15 +0100 | _d0t | (~{-d0t-}@user/-d0t-/x-7915216) {-d0t-} |
| 2025-11-19 12:12:24 +0100 | _d0t | (~{-d0t-}@user/-d0t-/x-7915216) (Remote host closed the connection) |
| 2025-11-19 12:08:31 +0100 | X-Scale | (~ARM@6.67.114.89.rev.vodafone.pt) (Ping timeout: 240 seconds) |
| 2025-11-19 12:08:10 +0100 | bggd | (~bgg@2a01:e0a:819:1510:3dbd:4461:e226:b31) (Remote host closed the connection) |
| 2025-11-19 12:04:24 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Ping timeout: 244 seconds) |
| 2025-11-19 11:59:50 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2025-11-19 11:59:45 +0100 | <tomsmeding> | if you do mutations to the IORef also in unsafePerformIO, if I'm not mistaken it is prudent to add {-# OPTIONS -fno-cse -fno-full-laziness #-}, but this may be cargo-culting |
| 2025-11-19 11:59:41 +0100 | deptype | (~deptype@2406:b400:3a:9d2f:445f:7a99:cca5:e330) |
| 2025-11-19 11:59:24 +0100 | deptype | (~deptype@2406:b400:3a:9d2f:a8bf:8a15:2c9c:d5b2) (Remote host closed the connection) |
| 2025-11-19 11:59:09 +0100 | <tomsmeding> | probie: yes, if the only thing in unsafePerformIO is the creation of the IORef and the usages are in normal IO, that's fine |
| 2025-11-19 11:58:35 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen |
