Newest at the top
| 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 |
| 2025-11-19 11:47:14 +0100 | m1dnight | (~m1dnight@d8D861A17.access.telenet.be) m1dnight |
| 2025-11-19 11:45:15 +0100 | qqe | (~qqq@185.54.21.140) (Remote host closed the connection) |
| 2025-11-19 11:45:10 +0100 | ubert1 | (~Thunderbi@178.165.175.248.wireless.dyn.drei.com) ubert |
| 2025-11-19 11:44:17 +0100 | fp1 | fp |
| 2025-11-19 11:44:17 +0100 | fp | (~Thunderbi@wireless-86-50-140-28.open.aalto.fi) (Quit: fp) |
| 2025-11-19 11:44:10 +0100 | fp1 | (~Thunderbi@2001:708:150:10::7e06) fp |
| 2025-11-19 11:42:07 +0100 | m1dnight | (~m1dnight@d8D861A17.access.telenet.be) (Ping timeout: 240 seconds) |
| 2025-11-19 11:41:07 +0100 | <haskellbridge> | <Morj> I believe this is a common pattern in some situations, like for logging |
| 2025-11-19 11:39:42 +0100 | deptype | (~deptype@2406:b400:3a:9d2f:a8bf:8a15:2c9c:d5b2) |
| 2025-11-19 11:39:23 +0100 | deptype | (~deptype@2406:b400:3a:9d2f:a44b:c20f:51e9:62bc) (Remote host closed the connection) |
| 2025-11-19 11:35:47 +0100 | <probie> | can you get away with a top level IORef (with the NOINLINE unsafePerformIO shenangians)? |
| 2025-11-19 11:31:15 +0100 | trickard_ | (~trickard@cpe-62-98-47-163.wireline.com.au) |
| 2025-11-19 11:31:02 +0100 | trickard_ | (~trickard@cpe-62-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-11-19 11:29:33 +0100 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) kuribas |
| 2025-11-19 11:19:31 +0100 | deptype | (~deptype@2406:b400:3a:9d2f:a44b:c20f:51e9:62bc) |
| 2025-11-19 11:19:17 +0100 | deptype | (~deptype@2406:b400:3a:9d2f:bc62:5450:375:9b3f) (Remote host closed the connection) |
| 2025-11-19 11:17:20 +0100 | trickard_ | (~trickard@cpe-62-98-47-163.wireline.com.au) |
| 2025-11-19 11:17:06 +0100 | trickard | (~trickard@cpe-62-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-11-19 11:14:32 +0100 | myxos | (~myxos@wsip-70-166-126-146.ph.ph.cox.net) myxokephale |
