Fork me on GitHub
#calva
<
2019-01-05
>
pez15:01:11

Everybody: I have just published a new version of Clojure Formatter which contributes a language grammar file of its own, for better syntax highlighting. Please let me know if it misbehaves on something. (It should be bug compatible with the vscode shipped grammar, but I’d like to know about misbehaviours even if they are shared with the original.)

pez15:01:17

@tomd: I build this grammar file the same way as the original is built. So you can send a PR towards here with your default changes: https://github.com/PEZ/language-clojure/tree/calva

pez15:01:08

(Make sure all tests run and all that. ❤️)

tomd21:01:26

@pez that's awesome, thanks! I'll take a look and send you a PR once tested (of course! 🙂)

tomd23:01:52

I made a (tiny!) PR. I noticed that def comes up on ln295 as well, but changing that didn't seem to make a difference when testing. I'm not sure I really understand what a meta expression is, so probably best I don't touch that.

lspector23:01:38

A little experience report for the devs, just because I'm not sure where else to put it and think maybe they'll see it here: I've been using Calva more and liking many things and thinking of adopting it for teaching, but I'm having a hard time getting past two things: 1) the inability to reformat unbalanced code 2) confusing feedback when trying to close up code. On 1, this is discussed in a github issue discussion and I think the way forward would be to format on the assumption that everything will be closed at the end of the file. On 2, the open bracket that's marked with a box sometimes matches the one before the insertion point, and sometimes the one after (if any). I think it should always be the one before, both for consistency and so that you will always see what matched a closing bracket that you've just typed. Also, typing a closing bracket sometimes adds one to the buffer and sometimes doesn't, if the insertion point was to the left of one like you tried to type. I think the first of these issues is unique to Calva in my experience, while I might have seen the second before. In any event, I guess it's combination that's making me squint and count parentheses, which shouldn't happen in a Lisp editor with bracket matching. I'm not sure of what'd be involved in addressing these issues or if there are aspects of them that I've missed. I'm mostly aiming for a kind of functionality available in other Lisp editors (many old... of recent Clojure tools Gorilla REPL and Counterclockwise did this well, and I think also some emacs configs and Cursive although I haven't used those for a while). To be clear -- I am really thankful that Calva exists and appreciate all of the work put into it!! But the things raised above are tripping me up quite a bit, and perhaps addressing them would help others as well.

mseddon16:01:25

As far as 1) goes, that is totally fixable- and in fact may not be too much work now we have a new incremental formatter (which I hope should have addressed a few of your concerns in https://github.com/BetterThanTomorrow/calva-fmt/issues/4, auto-indent should now handle unclosed forms correctly, but there is more work to do). Specifically, we now use an incremental formatter, based to some extent on emacs for auto-indent which we can also reuse to auto-close any open sexprs in your file before handing it to the formatter, so that is definitely on the radar. With regard 2) that paren-matching behaviour comes with vscode, and should follow fairly simple semantics (the cursor should match the close paren following it, by default, but if there is no paren immediately to the right, then it will try to match the paren immediately to the left). I am unsure if we can actually change this, or if you are experiencing bizarre behaviour that deviates from this. But, thank you for the feedback! Particularly in an educational context, getting this sort of thing right is vital, and I really appreciate where you're coming from, so am keen to get these issues resolved.