Fork me on GitHub
#cider
<
2020-11-18
>
bozhidar19:11:42

Here's the recording of my "Dark CIDER" talk from yesterday https://www.youtube.com/watch?v=IvTDzKVL58Y I hope you'll learn something new about CIDER from it! Enjoy! 🙂

dpsutton19:11:45

absolutely! great presentation @bozhidar

practicalli20:11:52

@bozhidar Auto-trimming was useful to know about, thank you. One thing I am not clear on. If I only evaluate in the source code buffer, does that mean the REPL buffer stays empty, i.e. no evaluation results, assuming I don't use side-effect things that print to standard out. So, if I don't evaluate in the buffer, I should not experience any slow-down due to long lines or many lines in the REPL buffer.

dpsutton20:11:55

trivial to check? inline evaluation does nothing to the repl

bozhidar06:11:12

Unless it produces output, like in the case of the issue I experienced during my live demo. 🙂

dpsutton06:11:28

yeah the trace over fibs 🙂 i've never used trace before and it looked amazing

Karol Wójcik09:11:28

Holy... What is that theme? ❤️

dpsutton14:11:25

It’s built in and called brin

Karol Wójcik10:11:53

Thank you @U11BV7MTK.

practicalli23:11:55

WelI have been evaluating in source code editor for the last several years without thinking about needing to clear anything, but after watching the talk by bug yesterday I just wanted to be sure I hadn't misunderstood something. I didn't want to tell people to avoid the issue of slowing down Emacs by just using the source code buffers without checking assumption.

practicalli23:11:52

I almost never have the REPL buffer open

dpsutton23:11:15

i always have it open and have my results there. if there are lots of lines, especially long lines it can slow down is all