This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-09-16
Channels
It's a bit annoying that when I'm editing text inside a double quoted string with Calva, when I type a (
[
or {
it autoadds the )
]
or }
. It doesn't autoadd a second "
when you type "
like it would outside a double quoted string.
And the paredit commands like slurp don't work. So there's not even consistency.
I'd rather have no magics at all inside double quotes.
I agree and I don't see this among the open https://github.com/BetterThanTomorrow/calva/issues
I agree this is annoying. At least you can delete it without paredit protection. See if you can find it mentioned in VS Code issues. It’s not Calva doing this. (Calva sets the default VS Code behaviour for Clojure file, but VS Code doesn’t offer a always, except in in strings option.) Otherwise I think placing the issue there is a good idea, unless the VS Code team has signaled that they don’t want to fix it. In which case we can discuss if Calva should be responsible for the auto-closing behaviour. If we make it so, we can do better than just add a closing bracket to the right of the current one, I think.
I feel that no matter what behavior you implement it would feel obnoxious in a lot of cases. I mean, when you first open a string, paredit will add the closing "
, so I suppose you're talking about automatically matching \"
? I feel we're suddenly outside paredit territory at that point.
I would actually suggest going in the opposite direction, and disabling paredit/strict completely inside string literals. I can't count the number of times I've been typing javascript in a string literal and been driven crazy by calva trying to balance my parentheses and tripping me up 🙂
Neither is any strict paredit enabled inside strings, except for deleting the opening paren.
What I meant was that if Calva takes care of closing brackets, it could be made to wrap the current form in situation like a |b c
-> a (|b) c
instead of just adding a bracket to side of the current bracket (`a (|)b c` like VS Code does. Inside strings it could be made to not balance parens at all.
I must have had some funk in my environment at the time then, because I quite clearly remember considering a noose and some stairs feeling like a real alternative to disabling strict mode for the tenth time 😅 It was some months ago, so I must admit I'm not very clear on the details
> Inside strings it could be made to not balance parens at all
this is what I would like
For the record: Calva treats strings as lists with words, where word is defined as anything enclosed by whitespace or the edges of the string. This means that this string "a (b) c"
has three words, and this one "a ( b ) c"
has five words, and that (
and )
have no special meaning. It also means that paredit commands are active in the string as if it was a list. But since )
is just a word, doing something like Peredit Raise from here "a ( b )| c"
, will raise )
and cause unbalance. It’s not ideal, but at least it’s deterministic.
> in situation like a |b c
-> a (|b) c
instead of just adding a bracket to side of the current bracket (`a (|)b c` like VS Code does
For me, this would be confusing and I quite prefer to use Wrap with or just slurping if I want the form to be included in my new one, but I suppose that's a matter of personal taste.
Yeah, as long as it is Calva handling it, it could at least theoretically be made a setting. (Though we try to avoid settings if we can.)
Ctrl+Shift+Alt+P isn't that much harder to press than (
either, tbh
Anyway, my vote goes to "not balance at all inside strings" whatever (if any) changes you make regarding "auto-slurping" etc
and thanks for the explanation about strings-as-lists, I understand now why I've had unexpected results when raising etc
Just one more question: javascript in clojure strings gets picked up as "embedded language", if that makes sense? I mean that the (most) javascript language features are applied, and I get intellisensey completions and suggestions. Is it possible that they're interfering with calva paredit in some way?
I have never had that happening, but sounds like it could interfere, yes. I wonder why that happens for you. Maybe you have some extension doing this?
Just to be clear, I'd prefer nothing to happen other than exactly what I type inside quotes.
As we all do. 😃 But to be clear, it should start as a request to the VS Code team, because it’s VS Code typing that extra closing paren.
It would seem to me they would have a setting for that and that Calva should default that setting to off
It would seem so to you, but you’d be wrong. 😃 At least afaik. If that setting exists, we can discuss what Calva should set as default. I’d argue that at that point it could be left up to the user to choose behaviour and whatever default the VS Code team has chosen should be considered.
yeah I see it happening in .txt files, which should do no formatting imho
I guess that's too much
That is up to the user to decide, I think. Calva has chosen to default to auto-close brackets, but it is just a default.
The problem, as far as I see it, is that there is no way to disable the behaviour inside strings.
right.
Is it possible to have calva/clojure-lsp use joker for linting instead of kondo?
I'm the only one on the team using vscode+calva. The others are all on emacs and doing their linting conf in .joker files. It would be nice to be able to use the same.
You could maybe get away with disabling all clojure-lsp linters and use a Joker linter extension.
(and yes, "we use joker because we get so many warnings with kondo" sounds funny to me too, but democracy and all that :face_with_rolling_eyes:)
Or match the joker rules with your clojure-lsp config. (Speculating, but it seems it should be possible.)
FWIW I think you could easily reduce the amount of warnings to the amount that joker supports by simply turning some things off
Most of them come from the heavy use of macro-wizardry. The wizardry is superb, but kondo needs some hand-holding to make sense of it. I am sure that Joker does too, only that I have to do it separately for kondo 🙂
and it's not a big deal, I am happy to herd kondo if it means I can keep using the IDE I'm comfortable with, I just thought I'd ask if there was a simple setting or something, for switching linter' that I've missed 🙂
I think the simple way to do it might be what I suggested above. There i a Joker linter extension on the marketplace at least. So it could work.
Thanks, I'll give it a try
e.g. to convert the following .joker file to a .clj-kondo/config.edn
{:known-macros [next.jdbc/with-transaction]}
;; ignore all linters in macro
{:config-in-call {next.jdbc/with-transaction {:ignore true}}}
;; ignore only unresolved symbols:
{:linters {:unresolved-symbol {:exclude [(next.jdbc/with-transaction)]}}}
you can probably even generate a configuration from .joker to clj-kondo using a simple script.
clj-kondo has much better support for really understanding the macro through static analysis so even navigation for locals start to work, etc. using :lint-as
or hooks but this requires more workyou can even configure clj-kondo at your macro definition:
(defmacro foo [x]
{:clj-kondo/config {:ignore true}}
;; weird stuff))
Calva is freaking me out. The code suggestions it makes seem AI driven. Is that the case?
I do have co-pilot running in vscode. And I know sometimes Calva asks me if I want a co-pilot suggestion. Is it now automatically using co-pilot for code suggestions?
I'm not complaining. Overall it's pretty dang good. Just very surprising to me
I have Copilot for my FOSS projects and it seems to be what is suggesting code snippets, not Calva (since I can compare behavior to my work projects which use Calva but have Copilot disabled).
But, yeah, sometimes Copilot does a surprisingly good job -- especially for writing tests -- but it can be terrible at closing parens correctly.
yeah noticed that just now...
I'm not surprised by how good (or bad) the suggestions are (if it is co-pilot) I was just surprised to see calva making too smart of suggestions, and hadn't really expected it would use co-pilot
I'm not sure what you mean about Calva being involved...?
If it is using co-pilot (and I think it is) I like it overall so far
Calva isn't using Copilot. VS Code is.
oh, ok, I'm re-surprised
I only started using vscode for clojure and thus calva, so not experienced enough yet
well I also started using it to play with co-pilot. and now I use vscode for remote server work at my job, but not co-pilot there
the remote server integration is A+ imho
Yeah, I have a free license for Copilot as a FOSS maintainer (thank you Microsoft!) but that means I can't use it for work -- otherwise I'd probably be enjoying what it can do for JavaScript when I work on our frontend app!
I don't know how Copilot does with Perl 🙂
I actually haven't met a dev friend yet who doesn't get the free license
I don't know for perl yet either. Still using vim there
Oh, there are lots of people who don't qualify... I know loads of devs who don't qualify!
makes sense. I just recommended it to some friends who do a lot of oss
would be interesting to know how that decision is made
Based on your GitHub account activity somehow...
The VS Code api for completions uses something termed providers. An extension can register zero or more completion providers. I think of it as VS Code asking all registered providers for their completions and then using the responses to update the ui. It gets a bit complicated with clojure-lsp in the picture. In a sense clojure-lsp is an extension providing providers. And Calva uses nrepl to get completions for the provider that Calva registers. I’m afk and don’t quite recall how we have wired things, but for the purpose of this thread, we can regard Calva as one supplier of a completion provider, and CoPilot as another supplier (I don’t know how many providers it registers). Anyway, neither nrepl, nor clojure-lsp does any AI stuff with regards to completions. Yet. Also, CoPilot uses an api for “inline” completions. I find these jarring, and run without it in Clojure code. Last time I tried they weren’t good enough to warrant the disruption of my flow. Maybe that has changed lately, I’ll have to try again, it sounds like. In TypeScript the suggestions are better, and there is much more boiler plate for the AI to help me with, so I most often keep them on there.
the inline completions are more helpful than not for me right now but I'm a #C053AK3F9