Clojurians Log v2

yeah, i kept scanning for list and then realized it was probably named something else. it is the one for s-expression right?

I just ran into a decision regarding syntax parsing of numbers in Calva. Generally I want to stay as close to https://clojure.org/reference/reader as possible. However what to do with something like 0xg? Currently there are three interpretations at play in Calva: 1. The syntax highlighter treats as <digit><symbol> 2. Current Paredit treats it as <junk> (mainly do to a bug that I am just fixing) 3. Paredit in my https://github.com/BetterThanTomorrow/calva/compare/parsing-issues treats it the same as the syntax highlighter. 4. The Reader treats it as an illegal number. The keen eye can see that 1 <=> 3 and 2 <=> 4. Heaving rubber ducked this now, I'm leaning towards that it makes most sense to stick to my ”stay close to The Reader" rule of thumb...

@pez possibly a similar situation, i chose to try to treat \o378 as an octal character even though the last digit is out of range: https://github.com/sogaiu/tree-sitter-clojure/blob/master/grammar.js#L142-L150

for 0xg if you anticipate that arising mostly because of being a typo, possibly it makes sense to treat it as a number

Yes, you seem to have arrived at the same decision there.

> for `0xg` if you anticipate that arising mostly because of being a typo, possibly it makes sense to treat it as a number Depends... Maybe it is more helpful as a user to see that it is not parsed as a number?

if it's possible to detect errors reliably and show them as such i agree

i don't think i get to choose that for tree-sitter unfortunately

I'm not sure it is possible. It is certainly easier to allow more hex digits...

regarding showing errors, i like to think that with clj-kondo around, i can rely on that 🙂

Does it have a linter for illegal numbers? If so I could choose the easy way out here. 😃

i'm not sure actually -- perhaps i should do some tests

probably it will crash the reader

it worked for \o378 fwiw

$ clj-kondo --lint bad-octal.clj 
bad-octal.clj::: error: Invalid digit 8 in unicode character \o378.
linting took 5ms, errors: 1, warnings: 0

...and 0xg:

$ clj-kondo --lint bad-hex.clj 
bad-hex.clj:1:3: error: Invalid number: 0xg.
linting took 3ms, errors: 1, warnings: 0

great work, @borkdude 🙂

thank @bronsa for his work on tools.reader

thanks @bronsa 🙂

ah, i suppose it's not surprising he is not here

Does it report the right position in the file for you? To me it always reports 1,3 regardless.

I realize that that is why I assumed that clj-kondo wouldn't save the day. Didn't see the squiggle, which is under (ns in my file. 😃

Further, in the precense of a 0xg in the file, all other linting errors disappear . Maybe this is what you meant by "it will crash the reader”, @borkdude?

Yeah, it does so when it doesn't know the location because of some bad error handling. It can be fixed probably, feel free to paste an issue

I decided to go for something as close to the Reader as I could. So soon both syntax highlighting and Paredit will treat things like 0xg as one, invalid, numeric token. (Same for something like 078.) Also soon Calva will actually start to treat numeric literals and some other Clojure text much more correctly. Follow this PR for progress (and please install the VSIX to help test the changes ❤️): • PR: https://github.com/BetterThanTomorrow/calva/pull/838 • VSIX: https://8550-125431277-gh.circle-artifacts.com/0/tmp/artifacts/calva-2.0.131-parsing-issues-6af8b95e.vsix

https://github.com/borkdude/clj-kondo/issues/1058

I actually got through the whole list supplied by @sogaiu (I think/hope). https://8580-125431277-gh.circle-artifacts.com/0/tmp/artifacts/calva-2.0.131-parsing-issues-f8e3c551.vsix. Please help putting it to some testing, Calva-friends.