This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-01-24
Channels
- # announcements (4)
- # beginners (37)
- # boot (13)
- # boot-dev (3)
- # calva (122)
- # cider (16)
- # clara (13)
- # cljs-dev (3)
- # cljsrn (8)
- # clojure (311)
- # clojure-denver (1)
- # clojure-dev (14)
- # clojure-europe (7)
- # clojure-italy (36)
- # clojure-nl (3)
- # clojure-spec (11)
- # clojure-uk (77)
- # clojurescript (91)
- # core-async (10)
- # cursive (9)
- # data-science (5)
- # datomic (46)
- # devcards (2)
- # emacs (6)
- # figwheel-main (15)
- # fulcro (51)
- # jobs (3)
- # kaocha (10)
- # nrepl (6)
- # off-topic (53)
- # om (1)
- # onyx (2)
- # pathom (5)
- # reagent (50)
- # reitit (26)
- # shadow-cljs (153)
- # spacemacs (17)
- # specter (5)
- # speculative (1)
- # test-check (19)
- # tools-deps (15)
- # yada (3)
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!)
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
.
I think @mseddon would like to know if you are a user of the paredit command convolute
, @claynon 😃
I saw convolute in some paredit guide, but I didn’t see any difference between it and emacs’ raise
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.
that sounds awesome did you guys created a new paredit system or are you integrating with some other “third-party” lib
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
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
refactoring is vaguely on my rader- i want to get nrepl-refactor
in there, so we will have some ciderness
but the bonus is that down the line, we will be able to stick all sorts of output in that console
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
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
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.
but no clojurescript support yet, clojurescript debugging is somewhat of an open problem in the clojure community afaik
though this is really cool http://www.stopify.org/
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
actually our repl totally does not understand ansi colours atm. but at least we can fix that down the line...
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
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 🙂
worth doing properly though. it doesn't seem to be TOO hard, just a matter of going through each system
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
We should have a bunch of nice new stuff coming in soon that smooths out some of the main issues
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.
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. 😃 )
"Here is more detail than you ever wanted to know about incremental analysis of clojure source"
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
it inserts the evaluation for the expression as a comment. either to the right or under the expression depending on space.
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.
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.
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.
@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
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:(
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?
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 :/
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.