Hi! Do you mean to evaluate several things in succession? There are a few Clojure constructs for that. The one simplest one is to wrap your expressions in do. So, (do (this) (that) (this too))

You can highlight multiple forms and use Calva: Evaluate Current Form (or selection, if any), which defaults to Ctrl-Enter on Win/Linux, and I assume probably Cmd-Enter on Mac. There is also Calva: Load/Evaluate Current File and its Requires/Dependencies to load in the whole namespace. Open the Command Palette and type "eval" to see all the different variants Calva offers for evaluating in different contexts.

This is a clojure-lsp issue, could you provide a sample project where I can test if the issue happens there as well?

Why is your build target on the classpath?

Shouldn't it be? lein calculates the classpath and includes it, and I assumed the compiled classes needed to be on the classpath to be found. Apparently I don't understand the classpath, but I also haven't done anything explicitly to change it from the default.

@UKFSJSM38 I will do that unless another answer presents itself first. I can't share any actual projects, of course. But all my projects do this, so it's a config thing and my configs aren't at the project level, so should be easy to recreate.

We did some classpath refactors some months ago, so there is a chance we introduced a bug, thanks

Typical project structure would have a src folder for the source code, and a separate folder for a build target. The classpath while building will should only see your src folder and any other folder that you need resources from. Then lein dumps the build into a separate folder which runs self-contained from your source.

- root
   - out
      (lein dumps stuff here)
   - src
      - my_project
         - core.clj
   - resources

That is how I am set up, and it is the default lein structure, but out is named target. But lein does add it to the class path.

The default regex does exclude it, and the lsp server info does show the paths it uses, which do not include target. But when I change a source file, the log mentions a change to a watched file, and suddenly the target file shows up. The json file in the clj-kondo cache specifically mentions the path to the file in the target folder.

Btw this is all on windows, if that matters.

(actually, lein specifically adds 'target\classes' to the class path, but that path includes copies of the source files)

Hum, the file watch may be watching the target and scanning it when lein recompiles it, certainly causing clojure-lsp know about that file

Definitely something we should try to avoid on clojure-lsp

@U4LCNMMGS please, open a clojure-lsp issue with a minimal repro repo if possible so I can try to understand and find a way to avoid file watch consider those files

I, um, I just tried a project I'd not previously opened in Calva, and can't repro it. I've been messing with configs trying to solve this and may have corrupted something. But yeah, if I can repro it I'll file an issue, and if I clean all the artifacts from the project I've been working on and it stops happening, I'll report back that it was a false alarm. Thanks!

A git branch change may help repro or a process like shadowcljs watching changes to source to recompile the target

Apparently Calva is doing that. I'm still figuring this stuff out, but this is straight clj, no cljs, so there aren't any watchers that aren't provided by some part of Calva.

Oh, the fact you have your folder called as out and not target or build, may cause vscode file watcher to not ignore and consider as code to be analyzed if changed... I'd suggest trying to check if renaming it fixes

no, it's called target. out was from skylize's example

I was the one who said out

OK, I'll start on a clean project to try to repro. I just got it to fail again on a "clean" project. The ones I couldn't repro on were single namespace projects, which might be related, but it's still doing it on the larger ones, even after removing all calva artifacts and re-opening.

Hmm, can't repro yet, but while lsp maybe shouldn't be linting those files, they sholdn't be there. lein doesn't put them there, nor does intellij/cursive. But in Calva in a project that has this problem, if I just hit ^S to save a file, even an unchanged one, it writes it to the target directory as well. Even if I just did a lein clean and the target directory doesn't exist. But so far I can't reproduce that in a blank project, or even any of my own smaller ones.

I'm sorry, I can't repro it In a small lein project, if you hand-copy a .clj file into the target/classes directory (in the namespace-appropriate location), lsp WILL lint it and update its cache, and it will show up if you check references on one of those functions. I think that's wrong, but it doesn't cause any of the other issues I mentioned. And of course, the source files shouldn't be there so it shouldn't ever happen anyway. In my larger projects, if you simply save a file in the source directory, it gets immediately copied to the target/classes folder, and linted, but then it notes all the functions as duplicated, and they show up as references, but go to declaration seems to pick the last one linted, which is usually the target/classes copy. And I can't make that happen in a new project.

If you open the target file or file watch report as a file to analyze it will mess things for clojure-lsp indeed, as it will consider as part of the project, not sure there is a easy way to fix that, as I mentioned, a repro would help a lot

yeah, I know. But when I mentioned copying it to target/classes, I did that with explorer, not from within vsc. I didn't have the file open, although, of course the target folder does show up in explorer. Since that's a folder it is supposed to ignore, I would have thought it wouldn't react to updates to it. But then, nothing should be writing source files there, so I can easily see that not being checked. I still have no clue what IS writing those source files, except that it's something in VSC/Calva/whatever else is loaded (and I only installed VSC to run Calva)

If I can ever repro the issue, I'll report it, but I've spent days on this, and don't know how much more time I can justify spending on it. (But then I'll think of something else to try and fall down the rabbit hole again.) sigh Thank you SO much for trying to help though!

Youall are heroic for looking for a way to solve this. The duplicates I can try to ignore, but when I "go to definition" and I land (unawares) in the "decoy" file in the target directory, I sometimes work there by accident. I think Leiningen includes target on the classpath in order for it to encompass AOT-compiled class files. As for how clj files get in target, I think it might be "lein test" or "lein package" or "mvn test" (with clojure-maven-plugin)... so, theoretically, if you had a lein file watcher that re-ran tests or something, then that might do it.

Yeah, I know it's a terrible experience since I already faced something like that in the past, that's why if there is anything to improve on lsp side, I'd love to help

Actually, if you watch the LSP logs, you'll see that the file written to target happens immediately, I don't think any other tools, even lsp, have had a chance to run

(I could be wrong, of course)

does that happens with REPL on or off or both?

off, definitely. I haven't even tried to tackle the dependency conflicts to get the repl to run yet. First, I have to be able to edit lol

yeah, one more reason to possibly be something to improve on lsp side

I'm no cljs heavy user, but I know it's easier to have target folders being updated when coding with shadow-cljs

I'm waiting to see if it starts again, but I shut down VSC, deleted EVERYTHING related to calva/lsp, and the target directory, and then started it again, and now it's not doing it. But it also seems to not be integrating the lint data properly

i.e. it doesn't show any problems until I open a source file, and then everything is unreferenced until I open the referencing file, and save one or both of them. So something's still off in that project, but it's not duplicating the source files

(that's almost more mysterious)

that used to happen when clojure-lsp classpath was not found, but recent releases we made that required showing a warning if the classpath is not found

https://clojurians.slack.com/archives/CBE668G4R/p1669946264057689?thread_ts=1660749276.346169&cid=CBE668G4R of warning

OK, I've reproduced it, but I had to use my parent project. Going to try the same steps after removing it, but I'll save this first. It takes 3-4 vsc restarts to start happening.

One more reason to switch to tools.deps. 😛🙉

Yep, I can reproduce the behavior where it creates the clj files under target, but not all of the other symptoms I mentioned (duplicate definitions, etc.)

I'm on windows

If a clean project is not reproducing, you might try the other direction. Clone the problem project, and start deleting things until it goes away.

This is a clean project. I had dirtied it up, but it works clean, that is what I just tested. But it takes 3 edit sessions, so I had started adding some of my stuff to see when it started happening.

The thing is, I don't know if this is really an lsp issue, per se. The issue is the files being written and I don't know what is doing that.

Also, I need to strip it down further if I can, now that I know the steps required

@U4LCNMMGS It is right and proper for clj files to be copied to target/classes because that's how they get included in the jar when you package a jar. Maybe the linter knows about file paths to not scan, but it scans the whole classpath and neglects to exclude the intersection of the classpath and the directories it intended not to scan

Is it? I've only used leiningen and intellij/cursive and neither of those does that. In vsc/calva this happens inconsistently (I have to stop and start it about 3 times before it starts doing it), but when it does, clojure-lsp will lint them. I don't honestly know enough about all the various tool chains to know whether it is reasonable to put them there, but if this is intentional, why is it inconsistent? But if it is reasonable, then yeah, clojure-lsp should avoid scanning them from watch events. The docs at http://calva.io actually mention this case (the target directory setup), though only in the context of cljs, and give a clojure-lsp setting to prevent that, but that setting doesn't exist in the clojure-lsp docs or sample settings file, which is supposed to show all the settings. I'm just confused. Does this happen to everyone then? Do people just ignore it all? I'm used to having decent static analysis with intellij/cursive and I find it helpful. Is that not something most people have or care about?

btw, I was wrong, the 2 files are written 450ms apart, so some other tool could have been involved, but clojure-lsp logs nothing between receiving those 2 events.

The default lsp config includes this setting, which should be ignoring the target dir.

:source-paths-ignore-regex ["resources.*" "target.*"]

Pretty sure the comment in Calva docs is in reference to that setting. But the default shown above should already cover it with a standard Lein project structure.

No, I don't. That setting is in effect. In fact, lein classpath returns a classpath that includes both resources and target/classes. clojure-lsp server info shows a classpath that omits those. However, if you write a source file to one of those directories while calva is running, clojure-lsp will lint it. If you then check the corresponding file in the clj-kondo cache, it will show the path to the file in target/classes.

Every LSP setting along with default values can be found here. https://github.com/clojure-lsp/clojure-lsp/blob/master/docs/all-available-settings.edn

LSP is not changing the classpath. But it should be ignoring things that come from those paths.

I was referring to the comment from https://calva.io/linting/ under "Exclude entire folders from the linter", which mentions the :use-source-paths-from-classpath setting, which does not exist in the file you just posted.

form my test project, the server info from clojure-lsp shows the following: "source-paths": [ "C:\\Projects\\lsp-test\\src", "C:\\Projects\\lsp-test\\test", "src", "test" ],

it doesn't change the classpath, it harvests source paths from the classpath, and removes those matching the regex you showed above, yielding a set of source path that does not include target/classes.

(and that project isn't exhibiting the problem at the moment, so switching to one that does) and yet when a file is written to target/classes, the clojure-lsp log shows: 2022-12-03T03:09:28.418Z DEBUG [clojure-lsp.server:55] - [Trace - 2022-12-03T03:09:28.418Z] Received notification 'workspace/didChangeWatchedFiles' Params: { "changes" : [ { "uri" : "file:///c%3A/Projects/farm-decider/target/classes/com/unifilabs/outcome.clj", "type" : 2 } ] }

Source paths from that project: "source-paths": [ "C:\\Projects\\farm-decider\\src", "C:\\Projects\\farm-decider\\test", "src", "test" ],

Outdated Calva docs. :use-source-paths-from-classpath was removed this June. https://github.com/clojure-lsp/clojure-lsp/blob/ee8ad07be39e9ecd6ced8ad53e4623f605896941/CHANGELOG.md#20220622-140950

I knew something was out of date. 🙂 I tried it anyway, but yeah, I assumed the clojure-lsp docs would be more correct. But I don't see a way to do what that setting says it does, and it explicitly was given as a way to avoid linting the target folder

(oh, and the reason "src" and "test" are in that list was from when I was trying that setting with different values, failed to remove my last attempt)

(removed those. behavior unchanged)

Just FYI, I created an issue about the outdated docs: https://github.com/BetterThanTomorrow/calva/issues/1988

@U02EMBDU2JU I have a first piece of feedback. While seeing my rich comment expressions as top level cells is super nice, I am terrified to run them automatically (by clicking say, execute cell and all below). It would be nice to opt-in some comment blocks for the auto-execute, or even opt-in comment blocks that should take part in the notebook.

Is there a better place to provide feedback than a Slack thread? 🙂

I think a ticket or a discussion on github would be best. To answer your question: I'm kind of opposed to add special stuff into the file to support notebooks. They are meant to be just run on normal clj files. In your case I'd put the stuff you just want to execute, like defn at the top of the file and the comment at the bottom. That way you can "run all above". Usually you shouldn't even need to, since the namespace was usually loaded anyway. That said, I would mind an option in the config that disables the comments being put into their own cells.

The other option I could see is having special ".cljnotebook" files that give you more stuff

I might also be convinced to put it into normal clj files if you come up with something that's very unobtrusive to normal clojure work 😉

Thanks for the reply! In my initial testing I thought that the notebooks are not connected to the already running REPL (I saw some execution errors and without feedback I thought I had to run all the above functions. When I tried again it worked so probably some error on my part.

I have a thread in ClojureVerse but I can move the discussion to GitHub if you prefer, is Calva the correct repo for this?

Yeah calva github makes sense