[FEATURE REQUEST] persist REPL history to a file --- [was: drop a CIDER REPL connection without killing the REPL buffer]

[mccraigmccraig]

i often find myself wanting to re-connect a CIDER REPL session to a different VM, preserving command history - often this is for comparing behaviours between different versions of the same software running in different VMs

currently the only way i can do this is to kill the VM, creating a zombie CIDER REPL buffer, and then reconnect CIDER choosing to re-use the zombie REPL buffer

having to kill the VM is not ideal - i often don't really want to kill it. it would be great if it were possible to disconnect a CIDER REPL session without killing the REPL buffer

[vspinu]

This proposal would unnecessary complexity both in implementation and for the user. Reusing volatile REPL history is just a shaky strategy. If you want to replicate commands, just create a script file and run it in different VMs. It's "the source is real" philosophy.

BTW, the "creating a zombie cider repl" or the "re-use zombie REPL" no longer work in dev CIDER. It was deemed a micro-management with little added value.

The following would be the recommended approach for your case:

• Jack-in in as many VMs as you like
• Create a script with all the commands
• Link the script buffer to each VMs in turn (C-c C-s C-b) and load the script

[mccraigmccraig]

i disagree:

creating a separate buffer of commands is great when you know what you are wanting to do, but i find it impractical in an exploratory setting

btw what is "volatile REPL history" ? surely the history is just an immutable sequence of commands ? perfect for event-replay !

i can use cider-repl-history to get at historical commands from one REPL buffer, and i can of course connect multiple REPLs, but i find working with multiple concurrent CIDER REPLs painful - i easily lose track of which VM i'm interacting with - i find it less confusing to only have a single live REPL connection, at which point cider-repl-history isn't so much use anymore

[vspinu]

btw what is "volatile REPL history" ?

It's not persistent by default. Your emacs crashes and boom, you have to rewrite from scratch.

In any case, your problem is real. But instead of focusing of how to ping-pong the REPL buffer around, it's probably better to focus on persistent cider REPL history instead. For instance, if you work in one project with a repl, start another session within same project, the new session should inherit the old history. And maybe repls should persist into the same file (configurable by the user).

This brings up the old issue of moving cicer-repl on top of comint which allows automatic persistence, but well, a topic for another day.

CIDER REPLs painful - i easily lose track of which VM i'm interacting with - i find it less confusing to only have a single live REPL connection,

Hopefully not anymore. With new connection API session are linked to contexts (project, directory and buffer) and one can no longer operate on a wrong REPL by mistake. If you have multiple sessions links to the same context then the most recently used session is picked automatically. This basically means that you have to keep a REPL open and all your commands will operate on that REPL. Simple.

[mccraigmccraig]

persisting REPL history into a file could work well for me

context identification may also work for me - is that already released ? i couldn't see anything relevant in the CHANGELOG.md

[vspinu]

persisting REPL history into a file could work well for me

Then let's create an issue for this, or relabel this one.

context identification may also work for me - is that already released ?

It's in dev, still experimental and not yet documented. See #2324.

[bbatsov]

I'm puzzled by your conversation - it has been possible to persist the REPL history to a file for years. See cider-repl-history-file.

[mccraigmccraig]

lol - pretty sure i don't know half of the things cider can do

if cider-repl-history-file is specified, how does it work with multiple repl sessions ? does it just append... and can i then browse and search through all my repl histories in later repl sessions (which is what i really want to do in this situation) ?

[bbatsov]

Yeah, it's shared history for all REPLs regardless of their session. With .dir-locals.el you can have a separate file per project if needed.

[vspinu]

Hmm. Forgot about it. I actually have that file configured :/

In any event, it would be nice to be able to configure cider-repl-history-file to save history in a project specific fashion. As an example, if cider-repl-history-file is relative, save it in a relative path from the project root. .dir-locals for every project just to accommodate this pattern is too much effort.

Another point of improvement is to make history clj/cljs specific.

[bbatsov]

Yeah, there’s plenty of room for improvement. Maybe we should also enable this by default. Not sure why we didn’t do this in the past.

On Thu, 28 Jun 2018 at 23:14, Vitalie Spinu ***@***.***> wrote: Hmm. Forgot about it. I actually have that file configured :/ In any event, it would be nice to be able to configure cider-repl-history-file to save history in a project specific fashion. As an example, if cider-repl-history-file is relative, save it in a relative path from the project root. .dir-locals for every project just to accommodate this pattern is too much effort. Another point of improvement is to make history clj/cljs specific. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2353 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGVyg0GW0zmzJcoemqTKESiBLKLp49tks5uBUclgaJpZM4U7S3r> .

-- Best Regards, Bozhidar Batsov http://www.batsov.com

[mccraigmccraig]

well i learned something, and nowl i've got something to work with, thanks @vspinu @bbatsov

shall i close this issue ?

[bbatsov]

Maybe we can keep it open until we at least file tickets for the improvements suggested by @vspinu. All of them are trivial to implement and I guess it's worth us keeping a track of those, so we won't forget about them.

[vspinu]

Could be closed in favor of #2363