Fork me on GitHub
Stefan T00:03:32

Not sure if this issue is specific to Calva or Clojure LSP, but often times LSP shows some stale clj-kondo lint errors in a file, or totally wrecked tokenization. Making a small “edit” in the file seems to trigger a refresh, but I feel like the refresh should be happening when the file gains focus. Has anybody else noticed this?


It's probably clojure-lsp issue, any way to repro in a sample project?

Stefan T01:03:04

Here’s a small example of stale lint errors

Stefan T01:03:17

Though it doesn’t seem to be consistent. Some changes to ns-a does instantly resolve lint errors in ns-b, some don’t.

Stefan T01:03:19

It’s also happens regularly after changing branches.

Lukas Domagala02:03:08

Yeah changing files that aren’t open won’t send changes to LSP. That’s kind of calvas fault. Your example looks like it’s an LSP issue though. LSP would have to relint all files where that function is used, not sure if that’s broken or not implemented


Probably it's not broken but it's missing some checks , I implemented this some time ago and it's called notify-references, it basically should check when you change a function arity or name or something and lint the usages or that function, the same reverse


@UQE9SS4DP feel free to open a detailed issue with steps to repro that issue, it would help a lot


Last week @domagala.lukas convinced me to try Calva, so I’m gonna use VSCode instead of Emacs as my Clojure environment for the next month or so to really give it a shot, today’s my first day on it. One question right off the bat though, when evaling something, I love that the result stays inline with the code and you can have several results all sitting right there to look at, but I find the highlighting of the expression a little too aggressive. Can I change the highlighting to a coloured underline or something in the line-number gutter or something instead of the green highlight?

❤️ 1
Lukas Domagala01:03:53

I’m happy you’re trying it. Feel free to ask questions/make suggestions. Currently, you can’t. I think the best you might be able to do is to change the color, but maybe not even that. To be honest, most of the time I don’t look at the inline eval since I’ve got portal running and the repl output open. @pez Would we be interested to provide some theming/styling options for this?


I like having the inline eval since having a full REPL window takes up space. Ideally I’d like it to pop up when an exception occurs so I can inspect a stack trace or open it manually to look at a larger result

Lukas Domagala02:03:25

Yeah, having the inline results look better is something we’re trying to work towards. It’s the biggest annoyance with vscode that that part is so hard to accomplish. We might be able to move the results to the top of the hover soon, which would be half way there for me.


Yea, I was about to suggest that. On hover you can get errors, would be cool if you could see pretty-printed REPL results on hover like that too.

Lukas Domagala02:03:23

you see the results on hover, just on the bottom of the hover


Ahh okay, I see

Lukas Domagala02:03:50

you can also add anything you want into the hover: ->Custom REPL hover snippets


Ohh nice, thanks!


Hmm, perhaps calva could optionally write the pretty-printed results directly into the file in a comment and then provide a way to remove all the comments that calva wrote to the file? Perhaps always override the last one?

Lukas Domagala02:03:13

I recently managed to add trace results to all the called functions with I still have to write docs for that though 🙂


So that for larger results you could still see them inline without needing to go and hover over the bottom of the result or look at the REPL window to see it nicely formatted?

Lukas Domagala02:03:18

Not sure, seems like then you can just have the repl or portal open 😛


What’s portal?

Lukas Domagala02:03:54 you can have it as its own window or inside vscode


I mean sure, I can have the REPL open, and that’s fine when working on a widescreen monitor, but not so great when working on a 14inch laptop and I already want to have two windows side by side or something

Lukas Domagala02:03:06

Yeah 14 inch might be a problem. I recently started having 2 files side by side and the repl at the bottom. Works great, but you do need a decent resolution


Yea, but I’m picky and also want to save on vertical space 😜

Lukas Domagala02:03:41

one of the good things about calvas repl being a file is that you can treat it like one. I.e. bookmark it so you can jump to it if you need to see the result. That might help if you only want to see it sometime


My first impressions of Calva though are very favourable though btw, don’t want to sound like I’m complaining about missing features - Cider doesn’t provide a good way to show large results inline either. I’m mostly working on widescreen monitors at the moment anyways, so I’m not hurting for space lol


Calva also has the ctrl+alt+o o shortcut to show the calva file whenever it’s closed which is very nice

Lukas Domagala02:03:36

No, complain away. That’s how we make the editor better 🙂 The inline result thing is just something we’re trying to improve but vscode gets in the way What you might also like is portals cousin reveal. It has stickers: Portal is working on providing the same thing.


Complaining is important, yes, but I still want people to know they’re doing a good job and I’m not all complaints!

👍 1
Lukas Domagala02:03:17

Much appreciated! Anyway, its 3:23 AM I’m off to bed 🙂


Ohh, yea, sounds good! Thank you for the help! Good night


@U01BH40EA0Z There are commands for evaluating to comments.


Also, welcome to Calva, and thanks for the feedback!


Welcome to Calva @U01BH40EA0Z!


I don't think you come out as complaining at all. First impressions are precious and I hope you keep sharing them, the good, the bad and the ugly. 😃


Here's a somewhat related issue (related to the thread start at least)


To help understand where Calva is coming from I can recommend reading


Ahh thank you @brandon.ringe! That’s great 👌


And thank you @pez! I’ll give that link a read! Liking what I’m seeing so far :thumbsup:

calva 2

Is there a way to have #_ comments greyed out? I see the calva.highlight.ignoredFormStyle setting, but I’m not sure what to add to the map to make it greyed out instead of still having syntax highlighting in those comments.

Cora (she/her)02:03:30

looks like it's css. maybe setting color to something would work?


Unfortunately not, I was also thinking that would work 😕


It changes the colour for local variables, but not function calls, macros, strings, etc

Cora (she/her)03:03:47

maybe try setting outlineColor?

Cora (she/her)03:03:25

or as an alternative set textDecoration to line-through so at least you have some other indication


It does dim the form for you, at least, right?


Yes they should be dimmed by default. Keeping the syntax highlighting is a feature that we don’t have a setting to switch off.

Jacob Emcken10:03:10

I experience it "working"... I don't remember doing any special setup for this behavior:

Lukas Domagala12:03:58

It’s graying out for me as well. How strong the gray out is depends on the theme. Dark+ looks like the one @USW6URK47 posted

Lukas Domagala12:03:01

But this reminds me: we should add a hotkey to set these types of comments. Way more useful than line comments in a lisp


Not following about the hotkey, @domagala.lukas. Can you elaborate?


@U01BH40EA0Z to elaborate a bit on my answer. It would be a lot of work to have an option for choosing between the current behavior and one where the syntax highlighting is removed. This is because the syntax highlighting happens as part of the lifecycle VS Code provides and which has no API. The dimming (or whatever style you set with calva.highlight.ignoredFormStyle) is applied by Calva, but probably the syntax highlight often is applied afterwards.

Lukas Domagala13:03:48

@pez By hotkey/command I mean: vscode has a “Toggle Line Comment” command which calva configures to set ;; . I’d like a second command or better yet, overwrite “Toggle Block Comment” that sets #_ either at the first paren of the line or on the current form. about the highlighting: we could try to add #_ to clojure.tmLanguage.json as a comment, but I think that would produce new problems and I actually want my #_ comments highlighted and greyed out so… 🙂


Way to bring the thread off-topic. 😃 I think the hot key combo for prepending the form with a #_ is ctrl+up #_ ctrl+-. About highlightning, yes, what I mean was that if we want to keep the current behavior plus graying out, that would be a lot of work. To remove the awesome feature of dimming out, keeping syntax highlighting, is much less work. But it won't happen on my watch. 😃

Lukas Domagala13:03:03

Derail, me? Never 😉 But I’ll look into writing a command that adds that comment type. I actually use it more than line comments


I think it is not worth a command. Too few keystrokes saved.

Lukas Domagala13:03:03

Apparently, I use that more than you 🙂 Then I guess I’ll look into how to make that part extensible from a snippet for myself:stuck_out_tongue:


I use it all the time: ctrl+up #_ ctrl+-. Or I am not understanding the suggestion.

Lukas Domagala13:03:25

Then it’s just that I’m way too lazy and I’d like this combo to be shorter 🦥


It has been suggested before. Several times, even. But never from someone that was ready to do the work. I regret saying it is not worth a command. Please add it if it makes sense to you. ❤️

❤️ 1

A thing I'd like is for Calva to move the bracket trail down to the next line when the current line is line-commented. CIDER does that.


(Or maybe not CIDER. It is probably clojure-mode.)

Lukas Domagala13:03:38

uh yeah moving parens out of line comments automatically would make me use fewer reader comments, so that would also solve part of the problem already. Just sounds way harder, but probably useful for more people


Yeah, start with the easy one. 😃

Lukas Domagala14:03:28

BTW don’t worry about saying no to my proposed features. Feature creep is a real problem so it’s good if someone has an eye on it, so there should probably always be at least two people who would find something useful. Plus if we decide something should not be in Calva main it’ll force me to make Calva more extensible which is also a good thing 🙂


FWIW I’ve definitely noticed at least one occasion in the last week when #_ comments stopped being greyed out. Reloading the window fixed it. So possibly there’s something flaky there?


Thanks for that datapoint, @U01EB0V3H39. Please file an issue. It might help us collect more clues.


I had a crazy idea regarding inline results - can you show the “peek” window programmaticaly? Perhaps we can "peek" into the calva-output channel...


We have similar crazy ideas, @U7PBP4UVA. 😃 It used to work like this, but it was very awkward so we reverted back to using the hover. We didn't open the peek automatically, but it wouldn't have helped.


I’d prefer not to go back to that.


Hopefully we get better support in VS Code for showing results inline soon.

december rebmeced13:03:46

Hi @pez. I have found your repository with gitpod example Do you have any working template for .devcontainers in vscode? Loks like it a bit tricky to make Calva features work in remote container for beginners like me.


Hi! There is no such template. Because I don't know what a .devcontainer is. 😃 Is it something you could add to the project via a PR? At least an issue on the repo about it is very welcome.

december rebmeced13:03:12

This thing: Very similar to Gitpod approach. Same Docker development container with all required devendencies and VSCode extensions.


Ah, thanks. I think I might have read that article some time, but didn't have the context to appreciate it enough. Please file and issue on the repo and I will have a look at it.

❤️ 1
december rebmeced13:03:15

Sure, thanks.

🙏 1

It's something to consider for this as well, would you agree?

december rebmeced14:03:35

It is. devcontainers it similar to Gitpod, but local.

december rebmeced14:03:51

Tell me if such issue isn't right place in that repo 🙂


I think it is a good place to start.

Jacob Rosenzweig20:03:08

Did you know that you can actually play with your function bindings in the REPL when you’re debugging a function? That’s awesome.


You mean bind the locals globally and play with them in the REPL?


Or are you referring to the debugger being paused at a breakpoint? In that case, you can play with the local bindings in the repl.

👍 1

The above is similar to inline defs named the same as local bindings, except you don’t need to inline def, but you do need to instrument the function or add a #break or #dbg manually. This might be much less work though, depending on the number of local bindings.


Thanks for pointing that out, @brandon.ringe! I decided it was worth making a video about. it.

🎉 1
calva 1
😃 1

I’m wearing that same shirt today! 😄

calva 1

I did not know about the debugger! I found your video very informative. Wow! Neat! Amazing!

calva 1