Fork me on GitHub
#cider
<
2016-07-05
>
jan.zy08:07:06

@malabarba: reopening the file did help. Thanks!

jan.zy08:07:00

Don’t forget to mention that in your future blog post;)

chrisetheridge12:07:43

could anyone help me with specifying an indent spec?

chrisetheridge12:07:58

the docs are a bit confusing

pesterhazy12:07:23

When I use cider with boot, cider-find-var jumps to a path in my boot tempdir. Is there a way around that?

pesterhazy12:07:26

hm... I'm using boot 2.5.5, cider/cider-nrepl "0.12.0" and cider 20160629.946

pesterhazy12:07:43

still jumps to the tempdir

radon13:07:42

@malabarba: Did you have any ideas on getting *nrepl-server* to mirror its messages to *cider-repl*?

roberto13:07:40

I’m getting this error now when starting cider:

[nREPL] Establishing direct connection to localhost:49716 ...
error in process filter: [nREPL] Direct connection failed [2 times]

roberto13:07:46

it just started yesterday

roberto13:07:02

I upgraded cider this morning and still have the same issue

roberto13:07:32

i have no idea what might have caused it. I haven’t modified my emacs configuration in months

roberto13:07:47

hmm, nevermind, I figured it out. Something screwed up my hosts file.

malabarba21:07:38

@radon what emacs version are you on?

malabarba21:07:50

@pesterhazy: It works fine for me. Are you sure these are boot tempdir and not clojurescript tempdirs? Also, maybe try 0.13.0-snapshot

malabarba21:07:38

(add-hook 'cider-connected-hook
          (lambda ()
            (save-excursion
              (goto-char (point-min))
              (insert
               (with-current-buffer nrepl-server-buffer
                 (buffer-string))))))

malabarba21:07:22

It'll just insert on the repl buffer everything that's on the nrepl buffer when you connect

radon21:07:49

What if it never connects? When something goes terribly wrong, e.g. with the dependencies, sometimes the REPL fails to even start, and I just end up waiting five minutes before I check *nrepl-server* and realize that the *cider-repl* buffer is never going to open. (This is the primary reason that the default behavior annoys me.)

radon21:07:57

But I will try your code, for sure.

malabarba21:07:07

that should never happen

malabarba21:07:15

if the server fails to start Emacs should tell you

radon21:07:30

I think I’ve gotten that a few times. But maybe I just needed to wait longer?

radon21:07:36

I guess that’s possible.

malabarba21:07:37

In that case cider prints the stacktrace on the *messages* buffer

radon21:07:48

Oh, well, yes, but *messages* isn’t open by default.

malabarba21:07:12

C-h e will open it. But you should still get a message on the echo-are

radon21:07:41

That’s probably true as well, but since the REPL for a large project can take several minutes to start up, I’ll be in the middle of other editing by that point.

malabarba21:07:53

In fact, I think the message is the entire stacktrace, so it usually resizes my whole window to make the echo-area fit the stack trace. It's quite hard to miss ^^

malabarba21:07:02

that's possible

malabarba21:07:16

We could popup the buffer in that case anyway

malabarba21:07:39

The user is probably interested in the exception

radon21:07:20

Yes, I think that would be good default behavior. I would still prefer the REPL buffer to open immediately, so it can show log messages even if the REPL server hasn’t properly started, but I can see why other people wouldn’t want that.

malabarba21:07:33

It's not that people wouldn't want that. I think it's more that it would complicate code.

malabarba22:07:31

The repl buffer is created when the repl connection process is started. Separating the two would not be worth the complications.

malabarba22:07:03

And we can't make the repl connection any sooner than we already do, because that's up to lein/boot, not us.

radon22:07:53

I am really very knowledge-less in the field of elisp, but it seems to me that it wouldn’t be too hard to make cider-jack-in create a buffer named *cider-repl*, and then replace the code that creates the buffer with code that uses the existing buffer (or creates a new one, if the first one has been killed by the user in the interim).

radon22:07:04

But, you know more than I do about how this works.

malabarba22:07:17

Except we already have code that uses pre-existing buffers (which applies to cases where a REPL has previously existed), and it would conflict with this situation. 🙂

malabarba22:07:34

Of course we can workaround it.

malabarba22:07:47

But that's how complexity slowly increases. 🙂