Clojurians Log v2

> pressing backspace at the beginning of the next line should fix it. parinfer exposes tabstop locations for this reason

e.g. in atom, pressing shift-tab will fix it, but backspace can be made to do likewise

> we don’t have access to the metadata about how certain forms should be indented. Which I wonder about what we could do if we pass that to parinfer. I want to resist the pressure to turn parinfer into an auto-formatter

there’s a lot of config for indentation options: https://github.com/clojure-emacs/clojure-mode#indentation-options

> many cases aren’t ambiguous, and even if it worked conservatively (didn’t do anything weird in ambiguous cases), it would be neat. I’m willing to look at cases if they’re laid out

I suppose you’re right that stickiness may not be that annoying

https://i.imgur.com/3xHXl4I.gif

@pez where is the source code for that version of the extension u uploaded? just want to make my team mates not worried about installing some trojan 😉

@onetom it's this repo: https://github.com/shaunlebron/vscode-parinfer

master from that repo, even.

Please note that it is not super smooth yet. Parinfer relies on that its editing commands are always carried out by the editor, which it seems the extension does not yet manage to get vscode to do as always as is needed. And sometimes it stops you from undoing, which can be a bit frustrating. What I do is that I toggle parinfer off when this happens, undo, and toggle it on again. And if your colleagues are using Calva, you should also know this: https://github.com/BetterThanTomorrow/calva-fmt#parinfer-and-auto-adjust-cursor-on-new-lines

Thanks. I got the message about the calva-fmt indentation issue when u mentioned earlier. What do you mean by "if your colleagues are using Calva"? What else would they use? Or I should rather ask what else should they use, since I'm just trying to get CLJS adopted in the company.

I think they should use Calva, but I am biased. 😃

I'm using Cursive and my other colleague use doom emacs and others use vs code

Those who use Cursive and Emacs should stick too those. Even as biased as I am, I will say that. But for vscode I think Calva is the best so far, especially for CLJS.

so im actually having a hard time using it... so i have this monorepo: https://gitlab.com/oax/state-channel-poc/ but the cljs project is in one of the subdirectories: https://gitlab.com/oax/state-channel-poc/tree/master/viz/states

Hard time using Calva?

and my nREPL setup is using nrepl/nrepl with clj -m nrepl.cmdline

yeah... it seems it was designed to be used with lein repl :connect from the top-level of a project...

if it's just using the built-in vscode terminal, i would have expected it to be able to just control an exiting one started manually...

There is definitely an unnecessary dependency on lein there, that I should fix. But there is a setting for telling Calva where the project root is. Let me check…

well... there might be multiple clojure projects within this repo, since it's a monorepo...

but i just saw in the calva readme under the "future stuff" section: > Open as many REPLs as you like. so i guess it's unsupported indeed...

in the meantime i will try what happens with a lein repl client

ah, i just realized that you are the main developer of calva 🙂 thanks for helping out!

Well, I haven't considered monorepos at all, other than noting that I myself do not use the calva.projectRootDirectory setting but rather open separate vscode windows in a repo at work where there are several projects (don't know if it qualifies as a monorepo)..

Unfortunately I am more like the only developer. But it seems that might be improving.

If you have the time I would be happy to get an issue filed against the Calva repo where you described the monorepo needs and maybe how you think Calva should support it.

> if it's just using the built-in vscode terminal, i would have expected it to be able to just control an exiting one started manually... Not sure I follow here, but currently Calva opens its own Terminal sessions in the built on one to be able to control them (even if limited). I don't think there is a way to get a handle to a user created terminal.

i don't think i can recommend any solution until i familiarize myself more with vs code. i was hoping i can switch to it from intellij because vscode feels a bit faster and less resource hungry, but so far it feels quite inferior compared to jetbrains ides feature wise 😕

re: terminal: i think i got what you mean

Well, you could describe how Cursive helps with it, maybe?

cursive have the concept of modules within a project, but that's quite a heavy concept and i don't think it fits well with the philosophy of vscode

Fair enough. I'll have to read up some on monorepos. Might holler your way when I try to figure out how to better support it. Seems like you have already given me a clue with that just opening REPLs at will would help.

I would be very happy to discuss monorepos and their benefits and issues with you, btw

I'm a proponent of them in the past 2-3 years and in 3 different companies my experience was that their benefits far outweigh their drawbacks

if you want to build a CI pipeline for a monorepo, you definitely want to have this kind of optimization to compute which subproject has changed in it: https://github.com/awesome-inc/monorepo.gitlab

then this is a great analysis of the concept: http://danluu.com/monorepo/

i think it was one of the first articles i've found about this concept. i actually started to use monorepos before i knew that they are a thing and they have a name...

Haha, I was just about to post that link to ask you if it was a good starting point. 😃

since then there are a lot more experience reports about them and here is an important one, which might instil confidence in others already based on its URL: https://trunkbaseddevelopment.com/monorepos/

Thanks!

Btw, vscode has some concept of multiproject workspaces that I haven't looked very deeply at. However, it rather seems to be the opposite; a way to create a mono-workspace from multiple repos.

now that you are saying, i've also seen that feature when i was going thru their changelogs the other week

but indeed, it's the opposite of the monorepo case

implemented some elastic tabstop functions to see how it works: https://beta.observablehq.com/@shaunlebron/elastic-tabstops

it might be a bit much to expect clojure users to start using tabs in source files

unless inferring tab characters from existing files to provide a guess becomes reasonable

either way, was nice to study this to get a better idea of the space that both tools occupy