Fork me on GitHub
#calva
<
2023-09-16
>
Ingy döt Net02:09:13

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.

2
phill11:09:56

I agree and I don't see this among the open https://github.com/BetterThanTomorrow/calva/issues

pez16:09:53

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.

Tobias Karlsson19:09:55

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.

Tobias Karlsson19:09:18

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 🙂

pez19:09:13

Calva does not try to balance your parens inside strings.

pez19:09:03

Neither is any strict paredit enabled inside strings, except for deleting the opening paren.

pez19:09:52

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.

Tobias Karlsson19:09:26

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

Tobias Karlsson19:09:54

> Inside strings it could be made to not balance parens at all

Tobias Karlsson19:09:57

this is what I would like

pez20:09:25

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.

Tobias Karlsson20:09:50

> 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.

pez20:09:45

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.)

Tobias Karlsson20:09:40

Ctrl+Shift+Alt+P isn't that much harder to press than ( either, tbh

pez20:09:35

It is enough much harder for most people not doing it, or even knowing about it.

Tobias Karlsson20:09:12

Anyway, my vote goes to "not balance at all inside strings" whatever (if any) changes you make regarding "auto-slurping" etc

Tobias Karlsson20:09:20

and thanks for the explanation about strings-as-lists, I understand now why I've had unexpected results when raising etc

🙏 1
Tobias Karlsson20:09:01

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?

pez20:09:46

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?

Ingy döt Net21:09:43

Just to be clear, I'd prefer nothing to happen other than exactly what I type inside quotes.

pez21:09:12

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.

Ingy döt Net21:09:39

It would seem to me they would have a setting for that and that Calva should default that setting to off

pez21:09:56

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.

Ingy döt Net21:09:00

yeah I see it happening in .txt files, which should do no formatting imho

pez21:09:15

In text files you can just tell VS Code to not autoclose brackets at all.

Ingy döt Net21:09:38

I guess that's too much

pez21:09:49

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.

pez21:09:44

The problem, as far as I see it, is that there is no way to disable the behaviour inside strings.

Tobias Karlsson19:09:58

Is it possible to have calva/clojure-lsp use joker for linting instead of kondo?

Tobias Karlsson20:09:00

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.

pez20:09:21

You could maybe get away with disabling all clojure-lsp linters and use a Joker linter extension.

Tobias Karlsson20:09:40

(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:)

pez20:09:37

Or match the joker rules with your clojure-lsp config. (Speculating, but it seems it should be possible.)

borkdude20:09:52

FWIW I think you could easily reduce the amount of warnings to the amount that joker supports by simply turning some things off

ericdallo20:09:56

The kondo warnings probably could be fixed with few lines of configs

Tobias Karlsson20:09:40

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 🙂

Tobias Karlsson20:09:36

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 🙂

pez20:09:20

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.

Tobias Karlsson20:09:54

Thanks, I'll give it a try

borkdude20:09:16

The config to disable linting inside macros for joker is almost the same for kondo

borkdude20:09:59

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 work

borkdude20:09:53

you can even configure clj-kondo at your macro definition:

(defmacro foo [x]
  {:clj-kondo/config {:ignore true}}
  ;; weird stuff))

Ingy döt Net22:09:51

Calva is freaking me out. The code suggestions it makes seem AI driven. Is that the case?

Ingy döt Net22:09:13

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?

Ingy döt Net22:09:52

I'm not complaining. Overall it's pretty dang good. Just very surprising to me

seancorfield23:09:49

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).

seancorfield23:09:26

But, yeah, sometimes Copilot does a surprisingly good job -- especially for writing tests -- but it can be terrible at closing parens correctly.

Ingy döt Net23:09:50

yeah noticed that just now...

Ingy döt Net23:09:22

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

seancorfield23:09:46

I'm not sure what you mean about Calva being involved...?

Ingy döt Net23:09:12

If it is using co-pilot (and I think it is) I like it overall so far

seancorfield23:09:25

Calva isn't using Copilot. VS Code is.

Ingy döt Net23:09:22

oh, ok, I'm re-surprised

Ingy döt Net23:09:17

I only started using vscode for clojure and thus calva, so not experienced enough yet

Ingy döt Net23:09:38

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

Ingy döt Net23:09:58

the remote server integration is A+ imho

seancorfield23:09:02

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!

seancorfield23:09:58

I don't know how Copilot does with Perl 🙂

Ingy döt Net23:09:23

I actually haven't met a dev friend yet who doesn't get the free license

Ingy döt Net23:09:49

I don't know for perl yet either. Still using vim there

seancorfield23:09:54

Oh, there are lots of people who don't qualify... I know loads of devs who don't qualify!

Ingy döt Net23:09:28

makes sense. I just recommended it to some friends who do a lot of oss

Ingy döt Net23:09:20

would be interesting to know how that decision is made

seancorfield23:09:48

Based on your GitHub account activity somehow...

pez08:09:06

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.

Ingy döt Net17:09:57

the inline completions are more helpful than not for me right now but I'm a #C053AK3F9