Hi! Interesting case! I think this could be built using #C03DPCLCV9N. The VS Code API has a workspace fs module that I think can be made to watch for changes. Let me know if you want to explore this route, I’d be most happy to assist.

There may be some tool out there already, solving it the shadow-cljs/figwheel way. Though something more integrated with VS Code would be nice here, as I think you may not want automatic reload from the AI edits. I recall finding some extension that makes a list of changed files. When I was frustrated with VS Code not making this easy at all.

Here might be some prior art https://marketplace.visualstudio.com/items?itemName=pokey.command-server Watches a directory for json that is written to from a “rpc client”. (in this case for issuing realtime vscode commands, outside of vscode js)

how about a command that checks the last git commit and reloads any clojure files referenced? aider does a great job of making a git commit with each unit of work. That may be less fragile than watching the filesystem.

I don’t think watching the file system is particularly fragile, but a system using git would work as well. Depending a bit what Ux you are after you may still need a watcher. Or, if you use the command-server that @U09D96P9B points to, you could probably use a git-hook.

Naming is hard 🙂

I think it's weird that the folder has to exist, and then Calva dumps a bunch of files into that folder, instead of letting you create a new folder as part of this...

I disagree with core vs playground -- the only reason anyone uses core at all is because that was a default that Leiningen added whenever you asked for a single-segment project name 😞 lein new foo => lein new foo.core essentially, to avoid a Java weirdness with package names, as I recall. We really ought to stop propagating that ancient decision.

Fair enough on the core issue. Ideally the process would ask the user both for the project name and for the namespace name. If getting the user's input on that is hard, though, I guess I'd prefer something as generic as possible (which I thought "core" was), maybe even myproject and mycode.... but really, I'm not too disturbed by minimal and playground... and I guess my main request, if getting the names from the user is hard, is to avoid underscore/hyphen.

On your comment about the folder having to exist, @U04V70XH6, I get a dialog (on MacOS) that includes a New Folder button, and I used that to create the folder... and then when you do so it takes you into the folder and you again have the option to create a New Folder (which I ignore this time) and also an Open button, and if I click Open at this point it does the right thing. I would agree that it is a little confusing, and you have to remember to press New Folder first and then Open once you've opened it. So I'll want to write that up for students, and ideally it'd be a little more straightforward... but at least it does let me create the whole thing from within Calva, and I don't think it's too bad.

Ah, so that's a difference between macOS and Windows then (or perhaps Windows + WSL in my case)... Are your students all on Macs or a mixture?

I get this first

Then just this

I can navigate with .. or edit the path, but the edited path must exist...

Good to know! My students will be on a mix of OSes.

On Windows VS Code also shows a regular Select folder dialog. I think that on Linux it is probably not so easy to do this so they have built that weird thing in to VS Code instead.

As for the underscore. I actually wasn’t aiming for beginners so much with the minimal project. It’s more meant as a quick way to get a repl running in a new/separate project. This first version has no knobs, but I think it makes sense to make it a bit more versatile if people actually find use for creating projects like this. I’ve been pondering an integration of deps-new. But holding it off a bit to see how people use the dumb minimal project first. All that said, I can change the name to not use underscore.

That strategy sounds great to me but I’d start even dumber, with no settings that may not be what people want and will be unexpected. By which I mean no new settings at all.

@U06BV1HCH and don't forget that what you want/expect is not typical even for Clojure beginners:grin:

But, yeah, skipping the _ - thing is definitely an improvement in my mind.

Why I like the deps-new basic project is that it has enough structure to see how tests would be setup and run, and how to build a library or application jar - which are things that beginners struggle with as soon as they try to move beyond just the REPL

@U04V70XH6 it's hard to quantify over beginners, but would anybody expect new projects to get settings that are different from the ones they set up for the application? You'd expect everything to work in new ways that you have to notice, hunt down, and reverse?

Yeah, I agree... I found it surprising that Calva's minimal project override my VS Code settings that would apply to other projects.

Adding to this old thread because @U0ETXRFEW's "not aiming for beginners" comment was bouncing around in my head. Of course that entirely reasonable but I'd like to contribute that if one can nonetheless avoid confusing beginners (e.g. by introducing the hyphen/underscore issue unnecessarily, or introducing settings that differ from what the user has specified previously) then that would be better. Plus, this "create minimal project" feature happens to fill what was a gaping hole for beginners, even if that wasn't the motivation for adding it. Previously, we had a situation that was similar to giving someone a new word processor and when they said "great, how do I make a new document?" we said "oh sorry, for that you're on your own. Here's a bunch of stuff to read and pointers to other tools that you might want to try." This has now been fixed (hurrah!) but it's sort of like the word processor now has a "new document" feature that doesn't let you name the document, automatically picks a name that has to be written two different ways in different places, and uses a template with weird fonts and other things that aren't what you set in your preferences and don't appear in an empty document that you import in any other way. Still this is much better than not having any way to make a new document at all! But it'd clearly be better if it let you name it, or at least didn't name it in a way that raised weird issues, and if it didn't use that strange template that overrides your preferences. I really am really grateful that I will now be able to replace those instructions for creating projects with simpler instructions for renaming things and explanations of the overridden settings and how to eliminate them, but this is now so very close to being perfect for beginners that I want to be sure that the nature of the near miss is appreciated.

In latest Calva the hyphen of the namespace name is removed. I don’t agree it was a problem, but I didn’t have a reason to keep it around. I also renamed the command to refer to a mini project rather than a minimal one.

I appreciate the change! But I’m curious about how it could seem to not be a problem. I remember great frustration in an early Clojure experience when nothing would work and I couldn’t figure out why. I don’t remember how I eventually found out that it was because of the way I named my project, which struck me as completely bizarre. The specifics of the hyphen/underscore swapping convention struck me as weirder still. I now understand how it came about, and maybe it’s the best solution to an unfortunate situation, but still it’s weird and unexpected. Why isn’t it a problem to foist this on a newbie who just wants to try to start using Clojure? Now that it has been removed from the new projects that new users will be able to create in Calva, I guess it doesn’t matter that we see it differently, but I am genuinely curious about how our perspectives can be so different.

I’ve hade my struggles with that unfortunate issue too. I wish it wasn’t an issue at all. But I don’t see where a correctly named file+ns would cause problems for anyone.

The reason a correctly named file+ns would be a problem in this context, in which you're not asking the user for a name but instead setting them automatically, is that they will probably want to change it. When they try to do so they'll see a hyphen in one place and an underscore in another, probably get confused and/or change them in incorrect ways.

Not sure. With the new name they won’t even get a hint about how to correctly name things that has more than one word. I think I will add something about this foot gun to the getting started project.

I tell students to name projects using only letters to start. They have enough strange new things to worry about with immutability, Lisp syntax, lazy evaluation, etc. Later they will indeed have to worry about multi-word namespace names, and then they'll get the full story. But I don't think this should be on the path to creating and working with their first project. If the tool asks them for a name then it might flag problematic ones, I guess. But if it's naming things for them, I think it would be best to avoid forcing them to confront these issues by including a hyphen/underscore in every project name.

As I see it no one would be forcing anyone to confront anything by including a multi-word namespace in the mini project. I think it is making things unnecessary hard for beginners to advice them to use one-word namespaces rather then tell them the basic naming rules for namespaces and their corresponding files. Naming is hard, even without one-word constraints.

Well they'll have to confront it when they try to name their project, since they'll be changing something that uses a hyphen in one place but an underscore in another. I could see justifications for sharing the weirdness of the rules at various times, but like the flexibility of doing it later, which we get from not having the weirdness already in the automatically provided name.

Hmmm, maybe we are creating an unfortunate coupling between the project name and the first top level namespace by naming the command + the namespace mini. The project is actually named when naming the folder to create the project in. This name is not restricted by any Clojure, or even Java, considerations. The mini namespace is not the name of the project. It’s probably better to instruct users to create a new top level namespace, rather than to rename anything. Keeping the mini/playground around is perfectly fine. If we named this playground/hello instead we would avoid the artificial coupling.

deps-new encourages a system of username/app-name as the top namespace, which is probably good practice…

Also, since it is common practice/convention with this artificial coupling… Regardless of the username top level consideration, we could consider doing something similar to what deps-new does when it names the project namespace the same as the folder. So if the user names the folder Gazonk the playground file would be created in src/gazonk/playground.clj. (And if they named it Cool Stuff, the file would be src/cool_stuff/playground.clj, but you could instruct your students to not name the folder with anything but letters.) Would take some re-design of how the feature works internally in Calva, but may be worth it, and avoid extra Ui/steps for naming things.

I am not sure I am following all of the possibilities and tradeoffs here, but FWIW the principle I'd favor would be that a user should need to know and do as little as possible to create and start working in a project that they have named. I wouldn't want it to grossly violate good practice -- so no single-segment namespaces -- but beyond that I don't know if I'd favor "better" practices unless they really don't require the user to know or do anything additional. And ideally the new project would be "blank" -- the equivalent of a new document in a word processor -- without any non-default settings. (Added: Because that would be the least unexpected thing, following the same principle of requiring the user to know and do as little as possible.)

My point of confusion was that a blank panel opened and my VS Code Explorer showing the files being created disappeared. It took me a few seconds to realize this was the new(-ish) Calva Inspector showing the values that were also being displayed in the output terminal that appeared -- the duplication seems weird, and hiding the Explorer seems "rude" -- "Where did my files go?"

The "old" REPL is available via ctrl+alt+o r -- Calva: Show/Open REPL Window -- which would probably be better for beginners, than either the Inspector or the (readonly) Output Window?

The other thing that I think might be confusing: The minimal project is created with a VS Code settings.json which means the experience in this project would be different to a manually-created project elsewhere.

In particular:

"calva.autoOpenInspector": true,
  "calva.autoOpenREPLWindow": false,

I think this would be more beginner-friendly?

"calva.autoOpenInspector": false,
  "calva.autoOpenREPLWindow": true,

I agree that the file Explorer being replaced by the Inspector is confusing. Better, I think, for the Explorer to remain visible and for users to know from instructions/exploration that the inspector is there.

Thanks for the pointer on Calva: Show/Open REPL Window. I agree that it would be better for this to be open by default. My perspective is that the normal REPL flow of "type an expression, hit return, and see results" should be available right away, without having to learn and execute an additional command. People who don't like it can hide it or change the json more easily than disoriented newcomers can know what they're missing, find it, and do it.

On opening the inspector, I'm happy that it exists by default, but agree it's not great that it hides the file view.

When you say "new REPL" -- which window do you mean specifically? The repl.calva-repl editor buffer or something else? Also, which setting have you turned off for closing brackets?

There’s no new REPL window/prompt. It’s the same old since many years, behaving like it always have. The way the prompt works is that it will try to evaluate what’s before the cursor, if the cursor is at the end of the buffer. It does no checking for complete expressions. Calva is really bad at treating incomplete code. It is basically an all bets off situation. What you can do is unbind the binding for the enter key evaluating anything and use alt+enter to evaluate and enter to enter new lines. That is if indeed you actually want to use the prompt. I see the prompt as a trap, which is why I am moving towards hiding it more and more as the default experience. We don’t really develop the prompt any longer. I’m experimenting a bit with making something much simpler for sending off things to the repl outside regular files. Nothing conclusive yet on that front, though.

Huh... I thought for sure that I could enter multi-line expressions in the old REPL and that it behaved as expected. I would definitely only have used return (on a mac, which I guess is enter) at the end of the expression, on whatever line it ended. I'm on a new machine now, and maybe that only worked because of some setting that I forgot I fiddled with previously?

I like the prompt! I would like the classic REPL experience to be available somewhere if possible, e.g. what clj by itself does in the shell, though it'd be better to have it indent to the right position after typing a newline.

You can do something like clj -M -m nrepl.cmdline -c --port < .nrepl-port`` To give yourself a clj repl prompt to the project. Or lein repl :connect if it’s a Leiningen project.

Thanks @U0ETXRFEW, but that won't indent properly or provide other Calva features like popup documentation, right? What I meant is that it'd be nice to have a regular REPL experience available within Calva where those things are available.

@U06BV1HCH As you are probably aware, many Clojurians think encouraging direct REPL usage is a bad idea and students should learn to eval code from source files instead (such as in comment blocks). And it's a lot of work to provide the sort of REPL experience you're asking for -- and the audience for that sort of experience is very small. If you want a "rich" command-line REPL experience -- separate from Calva -- have you looked at Rebel Readline? That does quite a bit of fancy stuff disconnected from an editor.

Thanks @U04V70XH6. I've looked at Rebel before and just did again. Looks pretty nice but there's some setup and learning friction that I that I'd rather avoid for teaching. I do know that I differ with many Clojurians on things like this, and I too often evaluate expressions in buffers, in comment blocks, etc. But I still love a good old fashioned REPL and I find it's refreshingly intuitive for beginners. Comments that aren't really comments is a kind of weird idea, the top-level/current form idea is straightforward but I'd rather not have stuff like that on the path to initial typing and evaluating expressions, macs don't have any key labeled alt (or enter, at least on the one I'm using now) so all of that requires explanation too, etc. All of this can be dealt with, of course, but these are some of the reasons I value a basic, old-fashioned REPL.

If you don’t disable the autoclosing brackets the current REPL behaves very much like how you describe you want it to work. The chances that it will start to work with un-structured code are extremely slim.

I guess that even this is hard, but to be clear I'm not interested in it "working with unstructured code" -- rather I'd just want it to leave that code alone until it is complete. And I know you know this from our other conversations but I find autoclosing to be a nuisance and I will always turn it off. I want the characters that appear in a buffer (or REPL input area) to be exactly the characters that I typed -- nothing more and nothing less.

Yes, I know. I just clarified where you disable the REPL prompt from working like you want it to.

Taking it as you are using the terminal output destination. I like it best too. Should probably make it the default. The thing lacking for me is that I can’t navigate the output, but I find ways around that. 😀

The output is indeed appearing in my terminal, but as far as I know I did nothing non-default to make this happen.

FYI you have some non-default config 😃 (The default is to send the output to the REPL window.)

Hmmm... I'm on a new machine and I thought I had documented all of the config changes that I made, and I don't have notes about doing this. Maybe my new setup somehow got infected by my old one in files I moved over? Is there a straightforward way to reset everything to defaults, after which I could re-do the settings changes that I had intended to make (turning off Auto Closing Brackets in two places and doing some other stuff to stop it from abbreviating outputs with ellipses in the REPL). I want to see what students will get when they make only the configuration changes that I give them, and then add to those if I think they're necessary to get the right behavior.

Maybe you have Settings Sync enabled?

The way to reset things to defaults is to open the user settings json (there’s a command for that), and replace the contents with an empty object.

Here's what I see when I do Preferences: Open User Settings (JSON):

{
    "editor.autoClosingBrackets": "never",
    "calva.paredit.defaultKeyMap": "original",
    "[clojure]": {
        "editor.autoClosingBrackets": "never"
    },
    "calva.prettyPrintingOptions": {
        "printEngine": "pprint",
        "enabled": false,
        "width": 120,
        "maxLength": null
    },
    "workbench.colorTheme": "Visual Studio Dark",
    "editor.stickyScroll.enabled": false
}

I recognize most of this as resulting from things I did (including some that I forgot to document 😱, for example turning off the stickyScroll thing), but is any of this about where the REPL output goes?

Nothing about output destinations there. Maybe you have updated those settings in the project you are using?

It's a brand new project, made to test the new minimal project creation functionality (thanks again for that!!). So I don't think so, unless there's some magic going on that I don't know about....

If it is the minimal project, then that explains it, because it has those settings. 😃

Why is it different? Can it be the same?

The same as my normal user settings, that is. Having set them up once I’d rather not have to set them up again for every new project. Not that I even see how to change them… but I’d rather not have to find out.

It’s set up in a particular way to make it easier to write instructions for it. You can delete the .vscode/settings.json file in the project.

In future versions we may add some step(s) where the user can make a few choices about the new project. For now it is just this.

Good to know. I will delete that and add instructions to delete it for my students. But shouldn’t a “minimal” project not include this extra, confusing thing? (And as may have gotten lost in an earlier thread, not raise the confusing issue of hyphens/underscores in namespace/file names?)

I missed your concern about hyphens/underscore.

A few threads back. If there are default names, it’d be nice if they didn’t use hyphens.

Better if the user could be asked for them, and more importantly better to have no extra magic like that json file.

We may add some knobs eventually. The json file will stay for now.

Okey-dokey. Maybe don’t call it minimal then?

Just got back to my computer (was on Slack on my phone) and looked in that json file, and maybe this also explains the unexpected auto jack-in? FWIW all of this unexpected stuff that's inconsistent with vanilla projects created in other ways is definitely a negative in my book. I can appreciate that the settings might be better, but the unexpectedness and inconsistency isn't good IMO.