I'm not aware of Calva directly supporting that action, but it looks like the Joyride docs have an example a of a script which toggles #_: https://github.com/BetterThanTomorrow/joyride/tree/master/examples#structural-editing

I was about to suggest you look at that example. Noticing that we don’t link as we should to the actual example: https://github.com/BetterThanTomorrow/joyride/blob/master/examples/.joyride/scripts/ignore_form.cljs I hope you add formatting and file a PR for updating the example. 😃 Let me know if you need any assistance.

does the highlight go away if you have (defn foo [x] x)? If so, the highlight is likely warning that the variable is unused. You can silence this by using x or renaming it to _x or just _ indicating you are aware it is unused and intend it to not be used

No, it's always there

I guess that depends on what it refers to. The yellow squiggle disappeared. 😃 I eerily recognize the problem, but can’t reach to where in my memory that would be stored… A few suggestions: 1. Is there hover info about it? 2. Is it just [x] that this happens with, or does it happen with [y], or [x y] too? 3. There’s an inspector something something Tokens and Scopes something something, that you can start from the command palette. See if it says something special about this token. 4. See if it happens with another theme. 5. If you haven’t installed VS Code Insiders, that will be a completely fresh install, with no settings and extensions. So that is a way to test if it is settings or extensions that causes this. a. If you don’t see it in a fresh VS Code Insiders you can start bisecting. i. Copy everything in regular VS Code’s settings.json to Insiders. (There’s a VS Code command for opening user settings.) If it appears, you know it is a setting. If it doesn’t appear, it could be an extension. b. If you are at where you now suspect an extension, it is probably easier to go back to regular VS Code and start Extension Bisect. It’s available from the command palette as well as from the meatballs menu in the Extensions panel. Now I ran out of ideas. Need more coffee. I can recommend Stuart Halloway’s talk about Sherlock Holmes. Haha.

Thanks @U0ETXRFEW! I'll follow your steps. Meanwhile, the highlighting only appears if the [x] is on an new line. Does not happen with [y]

That’s interesting. My main suspect is now an extension. I’m pretty sure it isn’t Calva, even though it is a bloat of an extension. 😃

I now tried to reproduce it. Couldn’t. So it at least it isn’t universal.

Does it happen in a JavaScript file?

It happens in any file!

And I found the culprit. It is the extension "Todo Tree".

Thanks for your help @U0ETXRFEW 🙏

Todo Tree. Noted. Then maybe it also highlights [ ]? 😃

It sure does!

(wrapped because outer light brackets become invisible)

It seems to think it's a markdown TODO. Maybe I need to look at this

Sweet! If you want to keep the highlight in markdown lists, Github style, maybe it is the sole ^ regex alternative there that you should remove.

Parens are a gift...

Your brain will hide them after enough exposure 🙂

After 5 years it didn’t 😅 actually I had a idea whether Clojure can be read without parens thus my question ;)

Interesting! If you find something, please let us know. Are you talking about only parens here, or is it curlies and hard brackets too? I’m trying to imagine reading Clojure code totally without brackets, and I fail. 😃

I don’t think you can make do without them completely, but you could make them very faint in the theme I guess. Parinfer kind of turns Clojure into an indentation-based language, but even so I wouldn’t want to not see them. Paren balancing can still get screwed up when copying/pasting. Still, it would be theoretically interesting to turn them off completely and only show them if there’s a balancing error.

As an exercise — I’m not sure I’d want to live that way. :)

Right fun exercise to make. I will try to play with theme settings and we will see how it gonna work ;)

The floating editor windows highlights my main grudge with the VS Code UI: Special layout for different content categories. Editors can only go to some places, panel content only to some. There is a thing that is Sidebar contents. And so on. Means I can’t arrange my content however I want. It’s totally unecessary. https://theia-ide.org/ proves this. Now when the VS Code team will deliver what must be the most wanted feature in a VERY long time, it will soon be followed by requests from people who want to float the Problems view. Or the File Explorer. Or the terminals (that may actually come out of the box, because they allow us to place terminals in the place for EDITORS) . Or the Debug console. Or… Why, oh, why have it like this? Yes, I should bring this to the VS Code team and not rant about it here. Thing is I have. https://github.com/microsoft/vscode/issues/68831. They closed it.

Here is @U0ETXRFEW, explaining all my reasons why I don't use VSCode 😄

I was just asking myself the same thing. What’s the role of (rcf/enable!) here?

it is a tool to keep tests out of prod and inhibit execution on namespace load, particularly tests in libraries

it is supposed to be controlled at the entrypoint, but if the test is sent to the REPL thread you always want it to run

Is there a way to test if a namespace is being loaded in the repl? If so we could do (rcf/enable! (is-repl?)).

Otherwise. How about this keybinding?

{
        "key": "ctrl+alt+c ctrl+alt+enter",
        "when": "calva:connected",
        "command": "runCommands",
        "args": {
            "commands": [
                {
                    "command": "calva.runCustomREPLCommand",
                    "args": "(clojure.core/refer-clojure) (require 'hyperfiddle.rcf) (hyperfiddle.rcf/enable! true) (println \"rcf tests enabled\")"
                },
                {
                    "command": "calva.loadFile"
                },
                {
                    "command": "calva.runCustomREPLCommand",
                    "args": "(hyperfiddle.rcf/enable! false) (println \"rcf tests disabled\") *3"
                },
            ]
        }
    }

; Jack-in done.
clj꞉user꞉> 
; Evaluating file: without-rcf-tests.clj
clj꞉some.namespace.without-rcf-tests꞉> 
rcf tests enabled
nil
clj꞉some.namespace.without-rcf-tests꞉> 
✅✅✅✅:last-form-in-the-file
clj꞉some.namespace.without-rcf-tests꞉> 
rcf tests disabled
:last-form-in-the-file
clj꞉some.namespace.without-rcf-tests꞉> 
; Evaluating file: without-rcf-tests.clj
rcf tests enabled
nil
clj꞉some.namespace.without-rcf-tests꞉> 
:last-form-in-the-file
clj꞉some.namespace.without-rcf-tests꞉> 
rcf tests disabled
:last-form-in-the-file
clj꞉some.namespace.without-rcf-tests꞉> 
clj꞉some.namespace.with-rcf-tests꞉> 
; Evaluating file: with-rcf-tests.clj
rcf tests enabled
nil
clj꞉some.namespace.with-rcf-tests꞉> 
✅✅✅✅:rcf
clj꞉some.namespace.with-rcf-tests꞉> 
rcf tests disabled
:rcf
clj꞉some.namespace.with-rcf-tests꞉> 

For less chatter, I think we will need to involve #C03DPCLCV9N.

Opening this file with Cursive, on the usage of fs there and doing "Go to declaration" points me at an external library under the name folder Leiningen: org.clojure/clojure:1.10.1 where it has the JAR clojure-1.10.1.jar which says google-closure-library something, and it's doing var fs = require('fs'); , which looks like some kind of library that wraps Node.js API

I’m not completely sure what to expect here. But if the destination is a JavaScript file, I don’t think we manage to resolve it.