This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2024-07-10
Channels
- # announcements (1)
- # babashka (17)
- # biff (7)
- # calva (6)
- # clerk (5)
- # clj-on-windows (1)
- # clojure (59)
- # clojure-austin (17)
- # clojure-brasil (1)
- # clojure-europe (40)
- # clojure-nl (2)
- # clojure-norway (103)
- # clojure-sweden (9)
- # clojure-uk (8)
- # clojurescript (8)
- # cursive (25)
- # data-science (5)
- # datalevin (7)
- # datomic (4)
- # emacs (8)
- # etaoin (13)
- # hyperfiddle (26)
- # lsp (8)
- # malli (7)
- # off-topic (9)
- # polylith (13)
- # releases (2)
- # sql (7)
I don't see one (I'm not an authority), but there is a "clear repl output" command, which might be useful, depending on context.
There isn’t at the moment, no. There is a control for how many lines get highlighted, which can slow things down a lot. As Bob mentioned, you can clear it manually.
The behavior I was seeing today was the REPL was truncating output that was "too long."
I didn't have time to debug it at all, but output from a single command was truncating results. (My Number of Highlighted lines is 100000.)
I can look a little more into where exactly it was truncating if that would be helpful.
It was getting me because I was searching history for a specific value, and it wasn't coming up. (This is something I'm used to doing all the time without issue.)
Do you have the exact message? I’m now using the IntelliJ console code behind the scenes, so it’s possible that’s configured in the IntelliJ config somewhere.
If you look in Settings | Editor | General | Console, there’s a console cycle buffer size, could you see if that helps?
ok, that does have an effect, but it can also cause the entire editor to freeze up for seconds. It doesn't appear to respect the "Number of Highlighted Lines" setting either.
for reference, the edn structure I'm printing is 214407 lines long (formatted with pprint), and 9.2M (formatted with pprint).
Hmm, I’m not sure about this - I’ll dig into the code and see if I can figure out what’s going on.
Great — increasing console cycle buffer size
seems to have worked
(background for me: I often run tests that produce tons of output (many log messages). It used to be that nothing got truncated unless I manually cleared REPL output. But, since maybe the last few Cursive eap versions, it seems like my repl output gets truncated at or before the syntax-highlighting limit.)
I've just investigated this to confirm, and it's definitely the console cycle buffer size settings controlling the output truncation. So you can either set that to be larger, or you can set it to 0 to turn the truncation off completely.
Is it some fundamental limitation that makes it impossible to rename scratch files with a corresponding ns
form?
If not, maybe it can be implemented?
Can you clarify what you mean? I’m not sure what you’re referring to with this. Scratch files are definitely a little weird, but it might be possible to do something.
Steps to reproduce:
1. Create a new scratch file - suppose it gets named scratch.clj
2. Put (ns scratch)
in there (helpful for :require
forms)
3. Try to rename the file
4. Get a "Cannot perform refactoring. This element cannot be renamed" error
A workaround:
1. Comment out the (ns ...)
form
2. Rename
3. Uncomment