Fork me on GitHub

Update on our application for Clojurists Together funding. We did not get it this time around. It was a long shot, of course, but would have helped us keep up the speed some. But, no worries! We will continue to work making Calva a productive and pleasant environment for beginners and experienced Clojure developers alike. In fact, we have some super exciting developments in the pipe as I type this. The first of which you might see released already next week. (And get to know more about this weekend. Stay tuned!)

🙁 20

I’ve seen some problems with paredit, but I’d guess that these problems are due to the library calva-paredit uses (paredit.js I think). This lib seems to be unmaintained. Is there any plans to do something about it. I ask this because I don’t want to open tickets that will definitely not be solved because this just generates noise and waste time of people filtering and investigating the issues. (And the problems I’m encountering are not too important. They are nice features or nice polishing, but not necessarily essential.)


@claynon please file the tickets. We indeed have a new paredit in the works, avoiding paredit.js.


will do, thanks

metal 5

I think @mseddon would like to know if you are a user of the paredit command convolute, @claynon 😃


is convolute the same as raise, right?


I saw convolute in some paredit guide, but I didn’t see any difference between it and emacs’ raise


I use it quite a lot


convolute is in emacs too 🙂


it is rather a bizarre operation


now I got it


I've implemented it, but.. I will not likely use it anytime soon 🙂


I don’t think I ever used that (especially because I didn’t know about it’s existence)


so yeah, there is a new paredit system, which we will integrate into calva shortly. We're adding a new repl ui and a proper jack-in soon, and need to do a bit of refactoring to get paredit in, but it hopefully won't be too long until we can move over to it.


it should be more robust in the face of strings and comments for e.g.


that sounds awesome did you guys created a new paredit system or are you integrating with some other “third-party” lib


this is a completely from scratch paredit, using lexically analysed source


it's not QUITE the same, but it's closer to emacs than paredit.js


additionally since it's using my incremental lexical analyser it should be much more performant in large source files, since it doesn't have to look at the whole file, it just updates it's model based on the changes you make as you type


cool, it will be easier for me to adapt to vscode moving away from emacs is hard I couldn’t adapt to atom (proto-repl seems to be unmaintained) but calva is making the change much easier


the fact I am stuck on emacs is why I am contributing to calva 🙂

😂 5

this big file problem made me waste a lot of time with emacs


yeah, we have long line problems, but big files are not quite as terrible


long line problems can be fixed too, but it's fast enough and there's many other jobs 😄


yeah, especially for clojure. I didn’t even know about this long lines problem because I never opened a file that suffered with that


I'm hoping calva supports your needs. If there are still issues I can revisit some of the crazy datastructures I employ to improve things, I think


my only problems at the moment with vscode are: refactoring, eval of a long file (but this will improve because I’m moving away from midje to use clojure.test soon) and support of escaped ansi colors on the Output tab


my output tab looks like this at the moment


refactoring is vaguely on my rader- i want to get nrepl-refactor in there, so we will have some ciderness


and oh god the ansi terminal crap


😄 for that we've gone all out and have implemented a REPL console from scratch


that’s awesome!


it should be ready real soon now.


it was a pain to write (and in fact, that's why I also wrote a new paredit)


but the bonus is that down the line, we will be able to stick all sorts of output in that console


images, dynamic controls etc.


but for now, at least it'll get us a more cider like repl


yeah I’ve been using quite a lot the repl in my terminal (outside vscode) because of this ansi problem but it’s a pain to copy and paste namespaces from the editor to terminal


yeah, it'll hopefully address some of that. It'll probably be a little rough around the edges for some workflows initially, but no worse than what we have atm


and a little bit prettier.


I’m surprised with calva. I think I’ve been using only vscode for two week and it’s the first editor that I try and don’t have to keep going back to emacs I’ve tryed neovim and atom before

metal 5

It's not too bad. The code is manageable, and getting better. I'm hoping once we have these last few 'big' components in, getting up to feature parity with cider will be fairly easy to do via small incremental PRs


well, i guess there's still nrepl debugger support to do, but other than THAT, I think we have an answer to most of the 'hard' parts of calva, even if they aren't shipped yet.


I’m curious to see a debug workflow in clojure, I never used this feature


it's not too shabby


but no clojurescript support yet, clojurescript debugging is somewhat of an open problem in the clojure community afaik


not impossible to do, by any means, just a lot of upfront work


though this is really cool


We (Nubank - the company that I work) have some macros that are basically (do (prn x) x) but with some colors (one of them is print that I send before) I usually use that instead of debugging, but a real debugger would be useful. I just never took the time to use it


🙂 yeah gets you a long way, too


actually our repl totally does not understand ansi colours atm. but at least we can fix that down the line...


it’s no worse than what we have right now


exactly. get the hard stuff up front out of the way, and then people have to solve 'render ansi colors' vs 'build entire repl console'


how is the support of calva for clojurescript? Since I started doing clojure I did almost no cljs


calva is pretty happy working cljs, specifically shadow-cljs and figwheel


I haven't tried the current extension with figwheel-main, but I'm adding support for that now in the new jack-in system, so it'll be there when that ships at least


I suspect it won't work with figwheel-main currently, just because I think if it's not detected a shadow-cljs project it immediately tries to use figwheel-sidecar 🙂


sounds like a lot of work to support everything


worth doing properly though. it doesn't seem to be TOO hard, just a matter of going through each system


I've added boot, clj, lein and shadow-cljs project launching now in my dev branch


the bit I am on now is detecting what cljs repl dance we need to do, so hopefully other than answering a few questions if it can't figure it out, running and getting connected should be nice and simple


do you have any plans in mind to present something about calva at any conference?


not myself currently, perhaps @pez thinks we should at some point? 🙂


perhaps Heart of Clojure, from what I got that’s one of the focus of the conference


We should have a bunch of nice new stuff coming in soon that smooths out some of the main issues


Oh, nice, and in europe too. I can actually get there without spending a fortune 🙂


At bare minimum it sounds like it would be a fun one to tag along to


yeap. I came to Europe not long ago and it’s been a nice change to be able to attend many cool conferences spending so little money


BTW I was also sad about Calva not getting the Clojurists Together funding this quarter, but I still think you should setup a Patreon page or something along those lines.

💯 15

It would be fun talking at some Clojure confs. Not sure would we would talk about, but @mseddon is really taking Calva to new heights so it could be a really nice demo, at least.


(And I have this passion for trying to ease the way for beginners into Clojure, so I could maybe talk about that some. 😃 )

❤️ 5

And then @mseddon can talk about all that advanced stuff.


"Here is more detail than you ever wanted to know about incremental analysis of clojure source"

🙏 10

yaaassss please!


I should definitely document the internals of that nicely


it's really not hard to use, but it's potentially a bit obscure


a perfect early morning talk before the coffee's kicked in 🙂


what is your vision for the repl ui you were discussing? Have you played around with rebel-readline at all? I'm totally digging it. It's still not quite as integrated as emacs/cider though with full auto closing parens and paredit, etc.


Also, does anyone use the eval-defun-to-comment feature in emacs/cider? I think it's just maybe because I'm a learner but I seem to be missing that one the most. I was using that all the time to let me quickly see what the function is doing.


@chase-lambert the initial repl will have paredit, paren matching and auto format, as well as syntax highlighting, but not completion initially. But rebel readline is awesome and I would love to get all that goodness in


What does eval-defun-to-comment do?


it inserts the evaluation for the expression as a comment. either to the right or under the expression depending on space.


Awesome, we can do that.

👍 5

sweet! something like alt-v ; or something. What keeps you from going all in on the alt-v vs C-M-v?


Meanwhile you can eval-replace, select top-level-form, copy, undo, and paste as a comment.


(Or, copy from the output pane, of course.)


the other thing i love about the emacs repl and rebel-readline is you can recall multi line arguments instead of just the last line. that would be crazy useful to get back.


Yeah we will have that in the new repl! The vscode terminal is yucky 😂


The one thing I wish vscode had was the ability to stick custom code in without having a heavy extension. Like init.el


But eval-to-comment sounds really nice, so that will be added. Please file a an issue for it so we have a place to remind us.


no prob. I get to learn how to file issues now! hahaha


File away! Always great to hear what people want


@chase-lambert, thanks for the suggestion. C-h k, is that how you look up command shortcuts in Emacs? In vscode you would do ctrl-shift+p and search for the command. It will show you the keyboard shortcuts, if they are defined.


I think that is the right command but in emacs after you call that help function it allows you to just enter a specific key chord or command and it shows you good info on it.


it's super awesome. emacs is actually great, but it's locking up on my computer and it always has little issues that just take up too much of my time. I find vs code a little more productive overall just in the since that I install an extension or two for a language and I'm off and running. i'm just hoping to keep my basic emacs keybindings functionality as I transition.


vscode only supports one level of key chording, so some emacsy bindings are not possible.


ahhh. yeah, i'm not a huge power user either. mostly just want to keep my hands on the keyboard while not doing vim style modal editing. so the basics are fine for me.


yeah I'd love to have more levels of chording in VSCode but have learned to make do without


I have no idea if it's possible, but would love to see (or build if I could only find the time) a which-key clone


atom has one


Typescript is easy! But I don't tgink vscode provides useful info there, I had a look recently :/


You can manually read user configs but extension provided stuff is a mess. Vscode needs some serious work to get up to emacs standard power:(


for me it's more, I hate typescript 😛


i did just see you are developing a lot of the extension functionality in cljs now? And then that gets turned into typescript at the vs code interface level or whatever?


Aha. Yeah that is my fault


I am optimizing time until parity to cider


Unfortunately I find developing in cljs for calva really nasty atm


But if I can add a bit more to it, we can make that more palatable


Ultimately, I want a vscode plugin for clj that I can use knowing emacs isn't the best choice. What it is implemented in is a lower priority than its existence ;)


Vscode extensions are a hostile, stateful place where things change behind your back. Low level debugging makes it far easier for me to deal with that gnarly weirdness


Long term I really want to have calva implemented in cljs though. It is just harder than it initially seems. If anyone can work out a sane way to have a repl into a vscode extension, that is the first thing you run into


Perhaps we could run a piggieback in there? I don't have time to play with that atm :/


With no debugger and no repl, cljs vscode development is fairly horrible atm.


So currently although there is some cljs code and a desire to extend that codebase, we have a large typescript bedrock that uses the cljs (calva-lib) as an external library. We haven't had the time to get a setup where you can nrepl into a vscode extension, so typescript acts as the lowest level of calva for practical reasons. If anyone solves that problem, we can swap typescript for spec and all feel better :)


nice! I'm just here for the chat to be honest. I'm just learning programming and keep playing around with too many languages and stopping at the beginner level tutorials. I have to stick with clojure first before adding ts to the mix so won't be able to help out for a bit.


We're really keen to make calva accessible and easy, so please feel free to ask away in here!


But yes, the implementation is a weird combination of typescript and cljs atm. One day we will fix that:)