This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-11-01
Channels
- # babashka (1)
- # beginners (28)
- # calva (28)
- # cider (8)
- # clj-kondo (1)
- # clojars (4)
- # clojure (20)
- # clojure-australia (1)
- # clojure-europe (13)
- # clojure-uk (2)
- # clojurescript (2)
- # conjure (4)
- # core-async (4)
- # cryogen (3)
- # datomic (17)
- # fulcro (3)
- # helix (45)
- # malli (9)
- # off-topic (6)
- # pathom (3)
- # re-frame (13)
- # reitit (17)
- # sci (1)
- # shadow-cljs (9)
- # sql (6)
- # tools-deps (11)
- # vim (17)
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
> 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?
regarding showing errors, i like to think that with clj-kondo around, i can rely on that 🙂
$ 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
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
I actually got through the whole list supplied by @UG1C3AD5Z (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.
Bug with quoted \n
and \r
fixed. https://8585-125431277-gh.circle-artifacts.com/0/tmp/artifacts/calva-2.0.131-parsing-issues-fa9200d3.vsix