This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-04-29
Channels
- # admin-announcements (1)
- # aws (10)
- # beginners (76)
- # boot (53)
- # braid-chat (1)
- # cider (80)
- # cljs-edn (3)
- # clojure (65)
- # clojure-belgium (2)
- # clojure-gamedev (2)
- # clojure-nl (3)
- # clojure-poland (1)
- # clojure-russia (39)
- # clojure-uk (14)
- # clojurescript (91)
- # cursive (62)
- # datascript (1)
- # datomic (9)
- # dirac (34)
- # emacs (25)
- # error-message-catalog (8)
- # events (1)
- # hoplon (88)
- # instaparse (1)
- # jobs (2)
- # jobs-discuss (6)
- # lein-figwheel (7)
- # luminus (43)
- # mount (5)
- # off-topic (7)
- # om (28)
- # onyx (61)
- # planck (4)
- # re-frame (27)
- # reagent (3)
- # remote-jobs (2)
- # spacemacs (3)
- # untangled (136)
@cfleming: I reported an error with the IntelliJ built in tool for exceptions in plugins, is that the right way to do it, or better report it as a github issue?
@cfleming: I am on the latest cursive on IDEA 15. Is there a setting that will not auto reindent open files? (parinfer turned on). it creates unnecessary changes in my git working copy
@stijn: Reporting like that is generally fine, thanks, but let me know here or file an issue if it’s particularly annoying - it can be hard to tell how many times a particular exception occurs from the tracker, or if it prevents something critical from happening.
well, it seems that everything is still working, but I got a lot of
IndexOutOfBoundsException: chars sequence.length:502, start:3116, end:3647
@moizsj: No, that’s an important part of how parinfer works. For indent mode to work correctly the file has to be indented according to its rules, and that’s what that does.
and then
com.intellij.diagnostic.MessagePool$TooManyErrorsException: Too many IDE fatal errors. Monitoring stopped.
@moizsj: I agree it’s annoying, and I’m considering an alternative to parinfer which would avoid that.
@stijn: That sounds quite bad, if you have the full trace there can you paste it here?
@cfleming: I like parinfer but I think i'll have to turn it off for just this reason. I work with large codebases and cant really afford to keep making commits for indents
@moizsj: Yeah, I know. It also gives me unnecessary merge conflicts when I merge across branches.
@cfleming: it'd be nice if parinfer could only do local indenting for the parts of the code that I am actually modifying
@moizsj: That’s more or less what I’m planning. It’s tricky to get all of the benefit of parinfer, but it’ll reduce the annoyance significantly too.
One thing that is really nice is that you can just duplicate the last line in a form, and it will automatically extend the form to include the new line.
Those operations would require specific handling in the action, and there are potentially a lot of actions that might need handling.
@cfleming: or another option - let parinfer reindent the whole file, but only if I start editing it first. and not do it for all open files.
that way i can gradually include the reindents in my commits as and when i touch those files (for other reasons besides indent)
It’s because the integration is driven by modifications to the document. Once I receive an event that the document is being modified, it’s too late to modify it myself first.
I thought about doing it when an action is triggered, but actions in IntelliJ are used for pretty much everything, and there’s no way to tell if an action will try to modify the doc or not.
The problem then is that the doc has already been modified in a way that may not be consistent with parinfer.
thats ok right? I mean treat it like parinfer was doing it the first time on file open (but after 1 edit). it'd be like parinfer wont work till you make the first edit, but at least it'll keep the working copy clean
but anyway, even with that, i still dont think i'd want parinfer to reindent the whole file. it would upset a lot of people during code reviews (unnecessary noise)
I’m actually not sure about that. If that first action is a parinfer one which assumes the doc is correct, then it will behave incorrectly in ways that paren mode might not be able to fix.
I’m not sure if more people are using Cursive for work than Atom (I don’t think Emacs has a useful parinfer integration yet), but certainly numerous people have told me that they can’t use it because of that.
I, for example, cant use it at work because everyone else uses emacs. so they woudnt be expecting all those indent related edits.
I’ve been planning an alternative, hopefully I’ll have a beta at some point that everyone can try.
is there an easy way to clear a single record from the REPL history? I had a huge data structure in my clipboard which i accidently evaluated in the REPL, and now it's superslow
I notice there’s a file named replstate.xml inside the .idea folder; no idea what would happen if you were to edit that or rename it, but...
I imagine you’d want to stop the repl first
and of course back up the file
Hmm, the history’s there, but yikes, not what I’d call easily editable.
Ok, just did a trivial edit, and successfully restarted the repl, and my change took effect, so looks like it’s doable. Definitely want that backup though, just in case.
@ckarlsen: you know about the cmd-up-arrow shortcut in the REPL, right?
(or ctrl-up-arrow on Windows? I forget)
It moves thru the repl history in units of one form at a time instead of one line at a time
same for c-down-arraw
*arrow
Does the following sound familiar? I open a ClojureScript with figwheel configured in IntelliJ, I start a REPL. So far so good. Then I open another ClojureScript project in a new IntelliJ window. I close the REPL in the old project, I close <localhost://3449> in Chrome. Then I start a REPL in the newly opened IntelliJ window which closes with the message: " Port 3449 is already being used. " When I kill two Java processes with the ( sorry: Windows ) task manager I can start the REPL in the second project. - Have I done something wrong? If not, who did?
Are you using :cljs/quit
to close the repl?