Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add the ability to “tail” the *nrepl-server …* buffer #1328

Closed
Josh-Tilles opened this issue Sep 16, 2015 · 15 comments
Closed

Add the ability to “tail” the *nrepl-server …* buffer #1328

Josh-Tilles opened this issue Sep 16, 2015 · 15 comments

Comments

@Josh-Tilles
Copy link
Contributor

Given a situation like the following...
_cider-repl_twitter-collector_

I'd like for the window showing the *nrepl-server …* buffer to scroll as new input comes in.
Here are a couple more screenshots that demonstrate the desired behavior vs. the actual behavior.

Desired outcome

_cider-repl_twitter-collector_

# Actual outcome

_cider-repl_twitter-collector_

@Malabarba
Copy link
Member

Now that the server buffer keeps track of all clients, we could also just forward to all connection(repl) buffers any messages it receives (subject to a user option).

That should also be an easy elisp hack, if anyone wants to try. 😉

@bbatsov
Copy link
Member

bbatsov commented Sep 17, 2015

Yeah, probably this'd be best. I was musing over a similar solution a while back. I wonder, though, what's happening for people who're using cider-connect.

@expez
Copy link
Member

expez commented Sep 17, 2015

This was implemented, discussed, and rejected previously #818

I ended up putting the pertinent code in my .emacs.d because I really wanted that functionality.

@bbatsov
Copy link
Member

bbatsov commented Sep 17, 2015

As I said before - the server buffer will never get "tail" functionality, but I'm pretty open to @Malabarba's idea to simply redirect the output to the matching REPL buffer. If memory serves I suggested something similar.

@Malabarba
Copy link
Member

Yeah, probably this'd be best. I was musing over a similar solution a while back. I wonder, though, what's happening for people who're using cider-connect.

An ideal solution would be doing this in a middleware, instead of cider.el. Then people without a server buffer would benefit too. That said, either option would be a significant improvement on the current situation.

@bbatsov
Copy link
Member

bbatsov commented Sep 17, 2015

You can go over #818 for more details. I don't think this can be done using middleware as it seems that the output is dumped directly by the Clojure process and has nothing to do with nREPL. I haven't looked into this in a while, but I believe no one had ideas how to handle this reliably...

On the other hand this seems to work correctly with reply, although I'm not sure it will work correctly if you connect with reply to a running nREPL server.

@Malabarba
Copy link
Member

It's not nREPL's fault, but the middleware can stil change the root value of #'*out*, can't it? Then the clojure process should respect that.

@bbatsov
Copy link
Member

bbatsov commented Sep 17, 2015

Hmm, something like this might work. We can probably send some init message to this middleware when cider launches. @cemerick does this sound sensible to you?

@bbatsov
Copy link
Member

bbatsov commented Sep 17, 2015

@Malabarba
Copy link
Member

Yeah, that gist is pretty much it. The middleware could also define a custom output stream that prints to all connected sessions, instead of just one.

@bbatsov
Copy link
Member

bbatsov commented Sep 17, 2015

Yeah, that sounds reasonable.

@cemerick
Copy link
Contributor

Yes, one can bash away at *out*, and it'll be picked up transparently.

This whole issues is related to http://dev.clojure.org/jira/browse/NREPL-4, but that's a far more ambitious, fiddly undertaking.

@bbatsov
Copy link
Member

bbatsov commented Sep 20, 2015

Once clojure-emacs/cider-nrepl#257 is merged this will finally be resolved.

@bbatsov
Copy link
Member

bbatsov commented Oct 7, 2015

Guess now we can finally add the scrolling support.

@Josh-Tilles
Copy link
Contributor Author

I'm happy to see that this was resolved, but I want to apologize to @bbatsov for (unintentionally) reopening a contentious topic: my bad.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants