This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-04-21
Channels
- # aws (1)
- # aws-lambda (1)
- # beginners (27)
- # boot (16)
- # cider (1)
- # clara (54)
- # cljs-dev (4)
- # cljsjs (8)
- # cljsrn (25)
- # clojure (148)
- # clojure-dev (2)
- # clojure-finland (1)
- # clojure-france (18)
- # clojure-italy (10)
- # clojure-nl (3)
- # clojure-russia (27)
- # clojure-sg (2)
- # clojure-uk (17)
- # clojurebridge (6)
- # clojurescript (70)
- # core-async (1)
- # css (6)
- # cursive (35)
- # data-science (3)
- # datomic (22)
- # events (4)
- # jobs (18)
- # jobs-discuss (14)
- # leiningen (4)
- # lumo (22)
- # off-topic (20)
- # om (5)
- # om-next (1)
- # onyx (47)
- # pedestal (107)
- # re-frame (43)
- # reagent (1)
- # ring (2)
- # ring-swagger (2)
- # rum (18)
- # sql (15)
- # unrepl (4)
- # vim (61)
- # yada (3)
Anybody feeling brave and want to test my ALE/eastwood/kibit integration? It should be really easy now
https://github.com/SevereOverfl0w/clojure-check/#editor-integration ← vim setup https://github.com/SevereOverfl0w/clojure-check/#repl-setup ← setup lein/boot
Good ways to check if it works:
(is (= 1))
← Eastwood
(= 5 (+ 1 4))
← Kibit will tell you to use inc
the golang is to make it completely irrelevant for you. https://github.com/SevereOverfl0w/clojure-check/releases here is an opaque binary. it just works™
@devth it was designed from the ground up for linking instead of an async replacement for :make
. It's way better.
Hi everyone, it has been a while since I logged in here. I've been working on this and wanted to get some initial feedback on the idea. It's not even near ready yet but am interested in any input. http://i.imgur.com/FE6OwDp.gif
@markwoodhall neat. I feel like I saw something like this with atom recently?
Not sure, It is based somewhat on LightTable.
@jebberjeb emacs does it
@markwoodhall that's amazing. I want it.
@jebberjeb I think atom does it better, because it limits the print, and you can click around to explore the data structure & expand it.
Something interesting unrepl does it create a reader and limit all print levels, so you get sequences like:
(1 2 3 4 5 <#C4C63FWP5|unrepl>/... {:get (tmp1234/get :G_128)})
and you can send (tmp1234/get :G_128)
to the repl to get the rest (recursively)
I'd love to see an easymotion-style mapping for expanding particular ones in a vim wrapper for unrepl
@dominicm started off working on it for the Mono C# Repl (https://twitter.com/markwoodhall/status/855445754206461952/photo/1), to use for the day job, but soon realised it would work nicely for Clojure. It works by trying to figure what expressions are in the current selection/line/file and evaling them with fireplace. It then iterates over all of the responses and appends them to the line at the end of the expression. When you leave the buffer or write to it the inline comments are cleaned up. There will be a lot of scenarios it doesn't work properly for right now. The video shows the plugin running in "Inline" mode, it can also run in "lastline" mode, where it will only show the inline comment for the last line in the selection/file/line, this is much more reliable, since it not trying to match repl output to expressions in the buffer. It also has a "bottom" mode, which will append new lines under the selection, which is rubbish.
@markwoodhall so it writes to the current buffer to make it work?
Yeah, it's best used in an Instarepl style buffer, where changes to the buffer are less of an issue.
I'm not sure, it sounds like it might be a good fit though.
Cool, hadn't seen that before.
Yeah, maybe.
I guess I was worried about the same kind of things as you, I figured people using filewatchers and stuff for auto testing wouldn't have many issues because it never writes the buffer. The biggest issue I could see was messing with the undu history, which I think is fixable. Again, in a buffer specific for a repl, most of these things don't matter.
or is there a case where the text could get left over? I think vim-easymotion used to have that problem (or does?). But it doesn't really break.
Will do, I think the only scenario it can get left over is a vim crash, otherwise the output should be cleared when you write/quit/move away from the buffer. I ended up making it harder for myself by getting greedy and adding support for other languages/repls, like F# https://twitter.com/markwoodhall/status/854775581266804739, node/C#/and a really dodgy vimscript eval https://twitter.com/markwoodhall/status/854373947974053888
I was about to suggest "a generic backend agnostic UI layer for clojure" But you've gone the other direction
The worst thing is, I started just trying to make it easier to work with C#, which doesn't really have a very good repl at all, so it was really painful. Now I've just gone off on one.