Fork me on GitHub

not sure if it's been posted before instant Calva in a future perhaps? :)


Maybe. 😃 It is very unclear so far what it takes. A member of the vscode team says this in a Slack thread about it: > The plan is for web-enabled extensions to work -- we are just getting started on this. I’m not 100% sure why its completely locked down right now, but I believe there were security/extension trust concerns we need to address. But believe me, we will definitely have a story for extensions.

sheepy 4
catjam 3

I somehow doubt it is using devcontainers. GitPod uses something like that. Calva can be run from the web browser that way, check out this repo However, it is hardly Instant Calva_ 😃 . The stuff seems more instant, and I am thinking that maybe it means that only parts of Calva will work there (once they get around to implementing the Extension Story and telling us how to use it).


Yeah, maybe it is codespaces. I am quite confused about all these things, tbh. I’m happy GitPod switched from Theia because despite a lot of trying from my side, I could never get Calva to quite work with that.


I don't know much about this stuff, but is using codespaces

🙌 3
Ryan Jerue12:08:05

My bet is that unpaid is the “free” experience while codespaces will be paid since one it would have to use some sort of resources. Don’t think we’re space age enough to run docker containers in the browser yet, but


More from that vscode team dude: > web-enabled and codespaces are two different things. So on (web), extensions run in a web worker and there is no node.js, where as in codespaces extensions can be run on the web side, but most run in the codespace “vm” itself, so it is more like the remote extensions > > I thought at first we had locked down, but I’m not sure that is actually the case. I think you can install any “web” extension in there. We will be coming out with guidance, etc about how to build/debug/test web extensions very soon. Right now the hold up is the debugging story (e.g. how to debug you web extension), which will be coming very soon > > And to be clear vscode web extensions aren’t some special or separate thing -- it is just a normal extension that is bundled for running in the browser environment (no node, etc), and in the browser there isn’t a real file system so it also needs to deal with virtual workspaces (which the guidance will also cover)


I read from this that will only be able to support part of Calva.


Updated all the plugins today and noticed what seems to be a slight conflict between Calva and Vim plugins. So I have this in a file: (my.ns|), with | representing my text cursor. Vim is in the insert mode. When I press Enter, it becomes this:

|  )
And if I disable Vim altogether and repeat the steps, it becomes this, which is more useful and, I believe, was the behavior before today's mass update of my setup:
Does anyone have a hint on where I should look to attempt to fix this?


Looks a bit like Calva loses a race against something Vim does.


Makes sense, given that without Vim, I sometimes notice how the cursor moves from the 0th to the 2nd column.


Calva does two things that affect what happens on enter. One is that it totally disables any auto-indentation that might be in effect: That effectively places the cursor on column 0. Calva also figures out how the new line should be indented, indents it, and moves the cursor to the first indent position.


> // (By outdenting a lot, which is the only way I have found that works) Huh. Is it something that other similar extensions use as well?


I don’t know of any similar extensions. I just wish VS Code had an API where I could tell it to not do any default indentation in a more civilized way.


I guess one such extension would be "Markdown All in One". Here's the code that indents a new unordered list item. Seems like it doesn't really indent anything - it just adds a new line with the right amount of spaces (which comes from the current line before Enter is pressed).


Not sure what the crucial differences are, but it works the same both with and without Vim.


FWIW, seems like Vim v1.21.5 was working just fine but v1.21.6 started putting the text cursor at the start of the line, like I described in the OP. But there were a lot of changes in between...


Facing the same issue. Not only the (ns) form but all the forms are suffering the wrong indentation.


Please add an example or two to the Vim issue - to at least increase its visibility, if nothing more.


@U2FRKM4TW Btw, do you know how to temporarily work around this issue?


Nope. Right now it's working again for some reason.


Good to hear that. I am waiting for my some reason to happen. 😉.


Well, yesterday was 22nd day of my PC's uptime, and now it's 23rd - pretty much the only thing that changed. :) Oh, and there was a suspend/resume cycle somewhere in there.


(Replying to an ancient thread about the cursor not indenting properly when using calva+vim) I think I might have found a decent workaround for this issue in the "regular" (not Neovim) vim plugin: You can add the "calva-fmt.formatCurrentForm" command to the keybindings inside the vscode settings.json file (can be done for any applicable bindings, I found o to be the biggest issue personally).

"vim.normalModeKeyBindings": [
            "before": [
            "after": [
            "commands": [


Is there any way to format the whole file? E.g. I entered a let form and my cursor is still inside it somewhere. I want to format it now, and I know for certain that the rest of the file is formatted. With Cursive, I would just hit Ctrl+Alt+L and it would do the job. With VSCode+Calva, I haven't found anything similar. None of the formatting-related commands seem to do it, except for the "Format and align current form", but for that to work I have to navigate to the let form itself - otherwise it doesn't work.


I guess it could be done via some external command that formats the whole file. But no idea what it will do to the cursor position.


Format Document should do it.


I would think so too. But it doesn't do anything at all.


Just checked with all the other extensions disabled - same thing.


Maybe there is some issue with some form in the file? Does it work in some other file?


Oh, there are different formatters, it seems. So I created a new file with just the default ns form and this

(let [a 1
         bb    2])
Formatting the form gives a nice
(let [a  1
      bb 2])
Formatting the document gives an ugly
(let [a 1
      bb    2])


And I would like the nice formatting to be applied to the whole document, of course. :)


Strange, but it looks like you have the align-associative setting enabled and that's what you deem ”nice”. I don't recommend having that enabled. It is very erratic.


I'm 90% certain it's the default setting.

"calva.fmt.configPath": ".cljfmt.edn"
and .cljfmt.edn does not exist in that project at all. Perhaps this line?


But what do you mean about it being erratic? So far, I haven't seen any random behavior, all indentations were consistent.


Hmm. Seems like cljfmt lumps all associative forms together when it comes to formatting. I'm quite used to maps (`{...}`) being formatted in one way (aligned) and all code (`let`, for, ...) - in another (not aligned). But I guess it's not really possible here by just changing the settings.


I guess I'll stick with an explicit :align-associative? true for now and see how it works out for me.


> I’m 90% certain it’s the default setting. If so, that’s a bug. One that I have not noticed, because it never formats that way for me.


> what do you mean about it being erratic? It often misbehaves. I probably should remove it, but I generally just recommend not setting it to true and instead use it on demand (that’s the command you found there).


Yeah, it's set explicitly at that line that I linked and works only for the calva-fmt.alignCurrentForm command.


Ah, so if you intentionally made it true for the on demand command then it's not a bug. But not that obvious as well.


FWIW, I would definitely prefer still having the ability to align all map literals in a file. It's way too frequent of an action during CLJS development for it to be available only on demand.


Not sure what you mean by not obvious, but the way the command works is that it formats with that option enabled.


By "not obvious" I mean that there are a few formatting commands, and while their names suggest that they differ only in scope, they're also different in their behavior. After all, that "align-associative?": true is implicit for the user.


The command is named Format and Align Current Form. That says it both formats and aligns, doesn’t it?


Indeed. However, the term "align" is ambiguous. The way I read it, at least initially, is "format the text of the form and then align the form relative to the outer document".


Fair enough. That’s what format does, in Calva speak.


As for enabling it by default. That takes a better implementation than what Calva currently has. I remember @UE21H2HHD recently flagging that he will not work much on it for a while. Maybe you can pick up the torch and bring it forward some steps?


Here’s the PR, if I am understanding things correctly:


I’m planning to get back to it, but had temporarily lost my cljfmt OSS mojo.


Yeah that PR is not from me and stale but does contain some recentish discussion. Further discussion is in the issue:


I was calling the feature “tabular alignment”. I thought that fit better.


Just to be clear - I'm talking about having an ability to have it enabled (as opposed to removing it, as you mentioned). Definitely not talking about it being enabled by default for all users. At the same time, I respect others' work, but I have 0% interest in anything that goes beyond very simple formatting like

{:a   1
 :bb  2
 :ccc 3}
and maybe
(let [a   1
      bb  2
      ccc 3]
(same for for, doseq, etc.) That linked PR #77 seems to me to be an attempt to solve every possible alignment scenario. That presupposes a lot of "what if"s, which I'm not a fan of.


There is some interesting discussion in the git issue.


@U2FRKM4TW, after giving it a careful read, it would be very helpful if you added your voice there with your ideas/concerns, etc.


If such advanced scenarios are truly desirable by some people, beyond speculation, then perhaps formatting can simply be made pluggable. I suspect it's feasible if rewrite-clj is used, but I can't be certain. > There is some interesting discussion in the git issue. Indeed. But I still strongly agree with these two particular quotes: > This all feels a little too clever to me, TBH and > Reviewing my code it seems alignment for hash-map and binding forms (defn, let and :require in an ns form) would cover 99% of all my coding. > it would be very helpful if you added your voice there with your ideas/concerns, etc. I'm afraid I don't have any ideas or concerns beyond what I have already described and what has already been mentioned in the issue - just a very bare-bones, the simplest alignment of something cohesive and associative. Just a single map or a single binding vector. Not a random vector of maps or, let alone, a vector of heterogeneous vectors.


If you have the time, I feel it would still be valuable to all if you chimed in on the issue to succinctly capture the concerns that you have raised here. Your input is valuable, it’d be a shame if it got lost.


Sure. But a bit later - perhaps, my brain comes up with a better wording by then.


No obligation of course! We are all volunteers! But thanks in advance if you find the time and words.


@U2FRKM4TW thanks for adding your not so humble opinions to the issue. Feel free to take a stab at it, I'm feeling less and less inclined to spend my time on this one.


Was my second guess correct though? :)


Which guess was that?


That the existing PR already contains what I personally consider a bare minimum - map literal and maybe let et al alignment working just fine in the most common scenarios with keys and values being on the same line, with values aligned to the same column.


Oh… that! Maybe!

👍 3

He seems to be pretty busy, but you might want to try to get weavejester’s ear on a plan.


Makes sense!


@U2FRKM4TW I was a bit emotionally invested in this one. I pretty much started my Clojure oss journey on this cljfmt feature when I discovered that rewrite-cljs and rewrite-clj v0 were unmaintained. I actually created rewrite-cljc (now rewrite-clj v1) in support of this feature which was not a small task for me. But I am curious and do often get distracted by other things, so best of luck to you on this one!


Thanks! I now realize that I might've been harsher than I could've been, and I sorry if it resulted in negative experience - that was not my intention.


I did find your tone a bit… indelicate? But… that feeling must have at least partly been due to my emotional investment. I like to watch from time to time. It helps me to keep my sweet demeanor. simple_smile

👍 3

(Replying to an ancient thread about the cursor not indenting properly when using calva+vim) I think I might have found a decent workaround for this issue in the "regular" (not Neovim) vim plugin: You can add the "calva-fmt.formatCurrentForm" command to the keybindings inside the vscode settings.json file (can be done for any applicable bindings, I found o to be the biggest issue personally).

"vim.normalModeKeyBindings": [
            "before": [
            "after": [
            "commands": [