Not sure. Maybe there isn't ... What you can try is to print the url and then pick it up with the regex.

Yeah, we didn't have that in the past, probably some vscode bump started to log that

The one triggered by unbalanced maps drives me bonkers. It should be a top priority if we want to try to pick and choose which exceptions to eat.

I think these are evaluation errors from my current REPL

Wow. That looks a whole lot more useful than what I see on my system for exception cases. All I see is Request textDocument/codeAction failed with a link to an equally opaque log entry in the Output Panel.

@stoubia’s exception is from evaluating, not from clojure-lsp, so different issue than yours @U90R0EPHA

Ahh. I see. ... So then why is he getting that as an exception? When I evaluate things, that just outputs to the repl doc.

Me too 😅

Actually I liked that feature and want to know how to enable it 😂

I think it was added recently. Do you start your REPL with jack-in?

Yes

But it's been some weeks I don't use Calva (I usually use it for testing lsp stuff or show to a new coworker)

@stoubia that error is from when you load a file. There is currently no way to auto-dismiss it. The only way to get rid of it is to fix the issue in the file.

@pez When you say "load a file", do you mean Calva: Load/Evaluate Current File? For me, that also just outputs to the repl. ??

@pez to clarify, the notification often sticks around even after evaluation errors have been resolved. I either have to close the notification manually or run the notifications.clearAll command.

Only if the REPL is visible. Otherwise it pops up that message. At least that's how I tried to do it. Added here: https://github.com/BetterThanTomorrow/calva/releases/tag/v2.0.302

@stoubia thanks for clarifying. I am not fully clear around how the dismiss works. Some message dialogs auto-closes, some do not... Maybe there is something we can do about it. Please file an issue.

I’ve been getting a similar popup a lot lately, while I’m in the middle of typing something. I especially notice it when I’m creating a re-frame event registration as I type {:keys [db]}. I think it generates three or four just while typing that out. I just tested it and the output pane shows four of these in quick succession:

[Error - 1:34:16 PM] Request textDocument/codeAction failed.
  Message: Internal error
  Code: -32603 

@UTFAPNRPT I don't know how similar that popup is, but both you and @U90R0EPHA seem to think so. 😃 Anyway that is an error happening upstream in rewrite-clj, and that we didn't use to see in Calva. It's unclear why it started to pop up, but probably something changed in VS Code's LSP client.

I'm quite aware this is sort of a different issue than I brought up. The original post lacked enough detail to realize that. Otoh, both cases involve undesirable error pop-ups to report parsing exceptions, instead of routing them into Code's linter reporting system. So it's really just 2 unique examples of the same problem. Parsing-exceptions should not be Calva-exceptions.

Which both cases would that be?

1. The case I brought up where rewrite-clj throws. 2. The case where a file fails to parse with no visible repl.

They are two completely different cases. 2 is a desirable message about an evaluation failure that could easily be missed if the REPL window is not visible.

Ok, yeah. That makes it pretty different. 😉

As for 1: If you have some time to study the LSP client and see if we can configure its behaviour with bubbling up errors, or if we can somehow catch this error, that would be great. Personally I can ignore pop-ups like this, but I know that for others that is almost impossible.

Some comments pulled out of the other thread. > undesirable error pop-ups to report parsing exceptions, instead of routing them into Code's linter reporting system. -@U90R0EPHA > I’ve been getting a similar popup a lot lately ... especially ... creating a re-frame event registration as I type {:keys [db]}. ... three or four just while typing that out. -@UTFAPNRPT > If you have some time to study the LSP client and see if we can configure its behaviour with bubbling up errors, or if we can somehow catch this error, that would be great. Personally I can ignore pop-ups like this, but I know that for others that is almost impossible. -@pez

If we don't have an issue for this, I think that's a good start. Also an issue is a good place to discuss this, because it gets more visible and more people can help with ideas.

Thanks for the issue! I've added some feedback there.

https://github.com/BetterThanTomorrow/calva/issues/1888

⁉️ Not sure what I pressed that caused 1888 to be submitted with no info. I'm gonna close it. Here is a complete issue filed. https://github.com/BetterThanTomorrow/calva/issues/1889

Just read your reply 1888, and edited 1889 title to be about the problem instead of the solution. Not sure what you mean about API for a cheaper solution. As a user, my expectation here is definitely that it would be reported like a bad lint.

What I mean is that the API might not allow this to be fixed at all, or it might allow for it being fixed and reported as a parse error. But if the API allows the latter it will also allow for just being silent about the error, which is how this used to be.

The popups are bad. But silent seems bad too. If my code is unparsable, it's going to break linting right? I would want and expect a lint report telling me "The lack or linting errors does not mean your code is okay".

Or will clj-kondo already report that successfully in this case?

If Calva can successfully relay a message from clj-kondo as a Diagnostic about a failed parse, then I am certainly all for just eating any exceptions from other tools hitting the same failure.

It worked without anyone complaining about it for years when it was silent. So that is clearly an option, as I see it.

I can't figure out Calva's involvement in CodeActions (which are mainly what keeps throwing). Best I can come up with so far is that we give LSP a provideCodeActions function as "middleware" when starting it, and then wipe our hands of the whole thing. Am I missing something

Happy to try and pound on this, but I'm really having no luck working out the whole relationship between Calva, LSP, and Code. I browsed through every single file in Calva source, read through (as best I could) every file that seemed vaguely possibly related, and read through every file in clojure-lsp source that mentions codeaction (case-insensitive), and still I don't have the slightest clue how a freshly-typed`:` finds its way through to LSP and back as codeAction exception.

Maybe @UKFSJSM38 has some tips?

First, this should only affect code actions not being available for specific text on lines, not linting or anything more otherwise would be a bigger problem. The issue is that, every time you move your cursor, calva asks for code actions, clojure-lsp tries to calculate parsing the current code and fails on rewrite-clj side, blowing a exception on the code action processing only

So I do think we should fix code actions not working on those specific cases but I think showing a popup is a little too much for the final user Imo

> ... calva asks for code actions ... > This is what I keep searching for in Calva, and I can't find it. Figured we could eat the exception, and decide if/how to inform the user. But I can't even see that Calva asks, beyond a tiny 1-line function in the initial config that seems to (I think) describe something about how codeActions can recognize locations in the file.

Cool that you have been around the Calva codebase, @U90R0EPHA! 😃 Most of this LSP thing happens upstream/on protocol level, though. Calva is ”asking for clojure-lsp code actions” when the client is initialized. It's part of the protocol. The exception is never caught and we get that error. I'm not sure we can catch that error. We've had similar situations before and I've never quite figured it out. This is what I have allured to when I say things like ”if the API allows for fixing this”. You could try focusing the debugger around here, and see what gives: https://github.com/BetterThanTomorrow/calva/blob/dev/src/lsp/main.ts#L135-L137

😔 So we are just introducing LSP to Code, so they can run off and play with each other. I was hoping I was wrong about that. I'll attempt focusing that fn again, but I tried already. Initial attempts to track from a breakpoint seemed to lead only to internal code and unreachable (likely LSP binary?). A try in there definitely fails to catch the culprit.

No idea if the [object Object] in the trace log hides any meaning.

Yeah, most LSP stuff happens on vscode-language-client library

Another thing you could look into is if we can intercept any VS Code error messages shown. I think the function is something like vscode.showErrorMessage but you’d have to check the api docs. If there’s no provided way, we probably can redefine that function to intercept calls. I don’t know for sure if that would let us intercept those specific calls though.

If we could intercept them, we can filter out those messages.

I have a pretty big TODO list with Rich4Clojure acting on the issues and PRs with fixes to some of the problems. My project for generating the problems is a big mess, so I need some quality time for it. But please don't hesitate to file issues about things there!

Ok. Don't worry! I inform you if I find something special. 😀

I think I've already said this, but I am super keen on feedback around #C03DPCLCV9N!

Ok! I keep that in mind! 😀

@U76D9RZRR I have a couple that I use a lot https://github.com/seancorfield/vscode-calva-setup/tree/develop/joyride/scripts to open a simple browser inside VS Code with either http://clojuredocs.org or Java Docs.

Thanks for the hint!