This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-03-17
Channels
- # announcements (7)
- # babashka (56)
- # beginners (114)
- # bristol-clojurians (4)
- # calva (22)
- # cider (7)
- # clara (1)
- # clj-kondo (17)
- # cljs-dev (1)
- # clojure (93)
- # clojure-europe (8)
- # clojure-italy (5)
- # clojure-nl (2)
- # clojure-uk (79)
- # clojuredesign-podcast (18)
- # clojurescript (108)
- # code-reviews (6)
- # cursive (3)
- # data-science (16)
- # datomic (151)
- # duct (7)
- # emacs (10)
- # events (1)
- # fulcro (76)
- # luminus (8)
- # off-topic (3)
- # other-lisps (2)
- # pathom (8)
- # re-frame (5)
- # reitit (8)
- # schema (9)
- # shadow-cljs (37)
- # specter (3)
- # sql (17)
- # tree-sitter (2)
- # yada (9)
I keep forgetting to change the defaults for this. 😄 Your question reminded me to do it for the next release.
Can Cider (or orchard?) detect if some result will result into an overly long line and do something about it?
Actual Problem: doing eval-print-result when the result is just a long long string (e.g. contents of a byte output stream) Emacs will freeze.
+1 I have this problem over and over again, the same when logging a lot of data on standard output.
Evaluating in the source code file always truncated output by default, so prudent to use that approach if you dont know what the result looks like, I used evaluation in the source code buffer when doing a web scraping project and avoided any Emacs lockups or slow-downs due to very long lines. Logging into a REPL buffer is always going to be messy. Given there are so many logging tools out there that are easy to add, I never had the need to do this. I dont think its a very effective practice, especially inside Emacs, as you are hitting one of the biggest limitations of Emacs.