This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (4)
- # aws (2)
- # beginners (48)
- # calva (39)
- # cljsrn (12)
- # clojure (98)
- # clojure-dusseldorf (1)
- # clojure-serbia (2)
- # clojure-spec (13)
- # clojure-uk (13)
- # clojurescript (97)
- # code-reviews (1)
- # datomic (14)
- # fulcro (24)
- # jobs-discuss (160)
- # juxt (1)
- # luminus (2)
- # nrepl (1)
- # off-topic (1)
- # other-languages (1)
- # overtone (1)
- # perun (6)
- # protorepl (16)
- # re-frame (20)
- # reagent (1)
- # reitit (6)
- # rum (8)
- # shadow-cljs (96)
- # spacemacs (8)
- # specter (4)
- # tools-deps (18)
- # uncomplicate (1)
- # vim (1)
@tomd: I will need the PR against the
calva branch of https://github.com/PEZ/language-clojure, otherwise I won’t be able to keep your changes when the file is regenerated. Sorry for the inconvenience, but running the spec in that repo to ensure the whole grammar still works after changes is a safety net we need. So, when having updated https://github.com/PEZ/language-clojure/blob/calva/grammars/clojure.cson you’ll need to also update https://github.com/PEZ/language-clojure/blob/calva/spec/clojure-spec.coffee adding test(s) that demonstrate that your change works. I run these tests in Atom, using
ctrl+alt+command+p. I also install the my dev version of the language-clojure in Atom and see that the grammar works there. Again, sorry for the inconvenience and for not documenting this process yet (I created it yesterday, is my excuse).
@lspector, thanks for the feedback! I’ll get back to you about it, but need to run right now. For bracket matching I recommend installing the Clojure Warrior extension.
@pez ah yes I should've read your original message properly! I'll do that when I get a chance. Thanks
@tomd , thinking about it, I should move everything in to the
calva-fmt repo. I'll do that tonight,
@pez thanks so much re: Clojure Warrior: that seems to play nicely with Calva and Calva Clojure Formatter, and to help quite a lot with bracket matching! Also, am I imagining things or did re-indenting of unbalanced expressions get improved recently? It seems at the moment to be working in at least some situations in which it didn't work before, although my testing hasn't been systematic so I'm not sure.
that's a big rework of the formatter, yes. I have moved it over to using lexical rather than parsed sexprs, which is improving the robustness considerably. However currently this is only used for auto-indent when you type return, it is not yet fully integrated into the rest of the format features
@lspector: I don’t think the indenting of unclosed things has improved. But you might try the new indent engine (enable it in the Calva Format Settings) and it should work more like you want it to. It’s what @mseddon is refering to ^ 😄
(The rest of the formatting features still will croak on uncomplete stuff, but the new engine offers hope that we will be able to fix it.)
auto-indent works better now yes, if you have an unmatched paren, but there is more work to be done to bring format current form etc. to that standard. I have put a note on https://github.com/BetterThanTomorrow/calva-fmt/issues/4, the end is in sight but there are a few little edge cases that need to be addressed to get it correct 100% of the time, which should be done so we can close it off for good 🙂
basically we can now easily close any unclosed sexprs because we can re-use the paren stack when we analyse for auto-indent, but we must take care to also fix up any mismatched close parens that are present, before we ship it off to cljfmt, or it will fail to read the expression, and hence format it.
regarding the issue with matching paren highlighting- we don't do anything special currently, vscode just does it out of the box based on the token stream it generates for syntax highlighting. the rule should be match the paren immediately (no whitespace) to the right of the cursor, unless one is not present, in which case if there is a paren immediately to the left, match that.
if you're seeing behaviour substantially different than that, something is probably up, but we will need to escalate it upstream to vscode
iiuc, vscode doesn't really let you customize the low-level paren-matching behaviour outside of the lexical grammar for the language, but I need to look deeper into that
I tend not to deal with unbalanced forms, so the formatter hasn't bitten me, but I shall have a look at starting work on a fix for that next week.
Oh! there is a weird bug in the grammar that ships with vscode that highlights close parens white instead of grey under certain situations, although I think @pez is working on a fix for that (or has fixed it) for a new release. That may cause some confusion.
I’m not done with that fix yet, @mseddon. I need to fix the update-grammar process first…
@mseddon I think what you describe as the vscode out of the box behavior is indeed what I was seeing. It's just that that's not great, both because it means there are often two different cursor positions for which the highlighted "match" is the same, and because sometimes it does/doesn't match what you just typed. This is complicated a bit by the fact that typing a close doesn't actually add one, but just moves over one, if you were to the left of the one you just tried to type. I understand that latter behavior is natural since closes are automatically added with open, which fwiw is a feature I'd also rather do without. In any event, I think that a lot of these matching issues may be less of a concern with Clojure Warrior enabled. I'll have to live with that for a bit to see.
I think there is a config setting that lets you disable auto-close paren in vscode but I am just about to go afk.
Looks good but if I go to Preferences, find editor.autoClosingBrackets and set it to "Never"... then type "(" in a Clojure file then it adds the ")" afterwards, as before
@pez you wrote "you might try the new indent engine (enable it in the Calva Format Settings)"... but I'm not seeing where to do that. I see how to disable/enable, but not any other settings. Regardless, I think the behavior I'm seeing is improving 🙂
About auto-closing brackets. Calva Format sets that to Always for clojure files, so you might need to set it specifically for clojure files to change it.
How would I set the auto-closing brackets off specifically for Clojure files? I can set it to languageDefined but then I don't see how to change what it does for Clojure
BTW since I've been being pretty opinionated I thought I'd articulate the underlying principle: I prefer behavior that's as close as possible to ordinary text editors that I and my students already know how to use, plus bracket matching and re-formatting. Other features that don't get in the way of editing, like popup documentation, are swell too. But I consider things that get in the way of ordinary editing, or break re-indenting or bracket matching in the wake of ordinary editing (like cut/paste that might unbalance things), are IMNSHO anti-features even if they might be helpful to people if/when they get used to them. Just FWIW!
@lspector, yeah, there are different paths here. I am a bit opinionated too, and tend to prefer the structured editing, made available by lisps. So, while I want it to be accessible to newcomers, I also tend to opt for keeping the structure of the code intact. So that’s why brackets are always inserted in pairs, and why Paredit get such a prominent seat.
@mseddon when you ask "Which editors are these?" are you referring to my comment about "ordinary text editors that I and my students already know how to use"? If so, then things like TextEdit on a mac or really just about any environment in which you type/cut/paste text in any application, like in an email program or whatever. Basically I just mean that characters the user types show up in the buffer, characters that the user doesn't type don't show up in the buffer, etc. I find anything that breaks these basic conventions to be problematic, both for my own use and definitely for many of my students. It's an unnecessary pain point for many newcomers.
BTW it's not just for the newcomers either. I've been writing Lisp for... geez, something like 35 years, and anything that breaks barebones editing is still a pain point for me too. Maybe because I also write a lot of non-code? Or because I write nonlinearly with lots of cutting and pasting? I don't know. Maybe that's just my personal pathology. But for newcomers it's definitely more general, as I regularly see students surprised and annoyed by things that break general bare bones editing skills. But I also think that re-indenting and bracket matching are absolutely essential
FWIW I also teach a fair number of students who are new to programming and intimidated by it. Last thing in the world I want to do is to break their basic typing and editing skills, which might be the one spot of firm ground in an alien landscape
@tomd: now I have moved the grammar stuff to the Clojure Format repo: https://github.com/BetterThanTomorrow/calva-fmt/tree/develop/atom-language-clojure
Thanks @pez. Do you still want tests added? If so can you give a brief explanation of what's needed?