It seems to me like that pop-up originates from clojure-lsp. Can you check the log?

Here's the log. • File contents`(/foo :bar)` • Cursor position (/foo| :bar) • Barf Forward Dev Console shows

[ExtensionHost] `_formatIndex`: Invalid symbol: /foo.

Thanks. Now the question is if clojure-lsp is doing something wrong to cause those pop-ups or if it is something we should be configuring in Calva to avoid. Please file an issue, @U90R0EPHA.

Happens before lsp starts. Thrown by _formatIndex in src/calva/calva-fmt/src/format.ts. It calls out to formatTextAtIdx which is really format-text-at-idx-bridge in src/cljs-lib/src/calva/fmt/formatter.cljs, and that farms out to format-text-at-idx. So far I've got it pinned to format-text-at-idx, as it goes in there with no indication of error, but comes out with a map that includes :error "Invalid symbol: /foo.". When it gets back up to _formatIndex, it throws because the error key exists. I presume this is intended to bubble up unexpected errors that prevent formatting with cljfmt? But in this case, it's throwing a what amounts to a lint error.

btw. Very annoying to wait for lsp to download everytime I reload a window. Would be nice if we compared versions instead of downloading blindy.

We only download blindly with nightly, I think. Hopefully most people are not reloading the window all that often. But you are welcome to file an issue, of course.

Call to cljfmt/reformat-string throws this exception

#error {:message "Invalid symbol: /foo.", :data {:type :reader-exception, :ex-kind :reader-error}}

It's probably rewrite-clj. See if you get a similar error with the new pretty-print-replace command.

Yes. Same error.

@UE21H2HHD do you think this should be reported as an issue in rewrite-clj?

@U90R0EPHA unless it isn't as obvious to you as it is to me. 😃 The pretty-print-replace command is not using cljfmt, but instead using z-print. Both are using rewrite-clj. As is clojure-lsp (or, rather clj-kondo), which caused some confusion about what was making Calva pop that message open.

I'll take a peek later. I did make a change to https://github.com/clj-commons/rewrite-clj/blob/main/doc/design/01-merging-rewrite-clj-and-rewrite-cljs.adoc#questionable-decisions... the thinking was maybe just don't use invalid symbols? Not fully awake yet... we are looking at an invalid symbol yeah?

Yes. And in the case of Calva, it's good that clj-kondo sees it as such, but bad that it's bubbling it's way up as an exception through cljfmt.

clj-kondo also uses an internal version of rewrite-clj. Rewrite-clj all around!

I think “just don’t use invalid symbols” doesn't work in editor tooling. The text, while being edited, will often be in an invalid state. The editor still needs to be able to help the user with formatting and structural editing.

Oh I think we might have https://github.com/clj-commons/rewrite-clj/issues/87.

Looks like a match. What are your thoughts after having almost 2 years to sleep on it?

Oh I’ve not been sleeping @U90R0EPHA! But not been thinking about this for 2 years either.

I’d have to ramp up on the issue again and invest time in it. If I remember correctly symbols were easier, other invalid source like unmatched parentheses harder.

Haha. No. I meant like "let me sleep on this" (to make a decision about something).

Oh I thought you were being a bit of a 😈! My apologies.

Assuming the worst for a moment, that might be too difficult to meet the needs of the use-case in that issue; is it generally useful to consumers to throw an exception here? In the case of Calva, such broken code is definitively not "exceptional", even if it prevents offering useful results.

Yeah rewrite-clj has a long history. It’s original author wrote it to update the version in his project.clj! It has been adopted for uses beyond his wildest dreams. Drop by #rewrite-clj if you wanna discuss. I’m a bit distracted with another project at this moment, but will try to respond… also I have a very talented co-maintainer who might chime in!

It's supposed to be THE build script. Not sure what's going on when ctrl+shift+b is not doing that…

It's showing me all the entries in package.json.scripts, and a tsc build and tsc watch for each of tsconfig.jsonand tsconfig.eslint.json. Is THE build script any one of those? Or is it supposed to be some other file?

Hmmm. Seems like I'm somehow missing .vscode folder, which I can see from Github is supposed to be included. I bet that's the problem.

Yep. That was the problem. No idea how that folder got deleted.

Do you think we need to clarify something on the wiki, or is it clear enough, given that you haven't mysteriously deleted the tasks?

My initial difficulty could not have been caused by missing VS Code Task files, because it worked fine running the build script command from the Command Palette. But now I cannot replicate the problem of calling it with a hotkey. So I can't really suggest any changes at the moment.

Could that have been some stateful behavior of VS Code? It remembered what had been in the deleted file.

No idea.

How would it remember something I had never used before?

It depends on when it was deleted. The file contains the instruction’s for starting all those tasks as you described it did. It seems VS Code could only have been informed from that file.