Hi all,
I've written a few functions that might be used to save the history of SLIME REPLs to disk. Those are attached as a file.
It might be an improvement to save the histories depending on the backend, I don't know. This is not implemented here.
Currently the list can be written to a file in two ways: 1. Just overwrite the file with the current history 2. Try to merge the file contents with the current list and save the result. You can see that from the docstrings.
Please note, that I did not test the truncating of the list to a maximum size. Also note that although I did test the functions, I have written them just a few hours ago, so they might still be buggy.
The defvars should be changed to defcustoms and the functions should be hooked to wherever they make sense.
If you are interested in using this code in -say- slime.el I'll pass copyright to you (as I state in the header of the attached file). If you prefer to receive a patch to slime.el I can do that, too. Just tell me.
Thanks for developing Slime, Kind Regards Stefan Kamphausen
* Stefan Kamphausen [2005-09-27 14:01+0200] writes:
If you are interested in using this code in -say- slime.el I'll pass copyright to you (as I state in the header of the attached file). If you prefer to receive a patch to slime.el I can do that, too. Just tell me.
Nice idea! Yes, I think we should add this or something like this. I wonder if we need explicit commands to load/save the history or if we should simply load it at startup and append the current line to the file every time when return gets pressed. I guess, I wouldn't bother to save the history if I need to invoke an explicit command.
Helmut.
Hi Helmut,
Helmut Eller heller@common-lisp.net writes:
- Stefan Kamphausen [2005-09-27 14:01+0200] writes:
If you are interested in using this code in -say- slime.el I'll pass copyright to you (as I state in the header of the attached file). If you prefer to receive a patch to slime.el I can do that, too. Just tell me.
Nice idea!
:-)
Yes, I think we should add this or something like this.
And again: :-)
I wonder if we need explicit commands to load/save the history or if we should simply load it at startup and append the current line to the file every time when return gets pressed.
That would be fine if the connection is always local. What would happen to a history with a REPL that is connected to a remote lisp? Write to local disc or pass it to the remote machine. If the latter it *might* be a performance problem. I can't tell because only work locally for the moment.
Since my code is very new and I haven't used it much, I think that someone will come up with a situation when it's not very intuitive...
I guess, I wouldn't bother to save the history if I need to invoke an explicit command.
What I currently use is a defadvice in my configuration files around slime-quit-lisp:
(defadvice slime-quit-lisp (around slime-quit-lisp-with-history activate) (slime-repl-save-merged-history) ad-do-it)
Regards Stefan Kamphausen
Stefan Kamphausen skampi@gmx.net writes:
That would be fine if the connection is always local. What would happen to a history with a REPL that is connected to a remote lisp? Write to local disc or pass it to the remote machine. If the latter it *might* be a performance problem. I can't tell because only work locally for the moment.
personally i'd much prefer the history be saved locally, i don't want to have production machines with development files lying around.
my 0.02EUR
"Stefan" == Stefan Kamphausen skampi@gmx.net writes:
Stefan> That would be fine if the connection is always local. What would Stefan> happen to a history with a REPL that is connected to a remote lisp? Stefan> Write to local disc or pass it to the remote machine.
I think the history mechanism should always go to the local disk as seen from the emacs in which SLIME is running.
Firstly, one may still have one common homedirectory (eg NFS mounted) even if there are many different machines. Secondly, one may always find other ways of sharing files across different hosts, this should not be the problem of SLIME to solve. Thirdly, if the code has a variable that allows the user to specify the name of the history file, one can always use one of emacs' network transparent file mechanisms (such as tramp or ange-ftp).
Finally, there is no thing as annoying as having problems getting out of emacs because some clever code tries to do something too clever on exit that it cannot complete, and networking the history has a lot of potential to aggrevate such a situation.
------------------------+----------------------------------------------------- Christian Lynbech | christian #@ defun #. dk ------------------------+----------------------------------------------------- Hit the philistines three times over the head with the Elisp reference manual. - petonic@hal.com (Michael A. Petonic)
Helmut Eller writes:
- Stefan Kamphausen [2005-09-27 14:01+0200] writes:
If you are interested in using this code in -say- slime.el I'll pass copyright to you (as I state in the header of the attached file). If you prefer to receive a patch to slime.el I can do that, too. Just tell me.
Nice idea! Yes, I think we should add this or something like this. I wonder if we need explicit commands to load/save the history or if we should simply load it at startup and append the current line to the file every time when return gets pressed.
Ahhh, you want to kill my poor iBook's battery!
I guess, I wouldn't bother to save the history if I need to invoke an explicit command.
Are you sure? What if the REPL were considered just like any other file-backed buffer, and C-x C-s saved it, C-x s prompted you about it, and exiting Emacs would ask you if you wanted to save it?
On Wed, 28 Sep 2005 12:10:38 -0700, tfb@OCF.Berkeley.EDU wrote:
Helmut Eller writes:
- Stefan Kamphausen [2005-09-27 14:01+0200] writes:
If you are interested in using this code in -say- slime.el I'll pass copyright to you (as I state in the header of the attached file). If you prefer to receive a patch to slime.el I can do that, too. Just tell me.
Nice idea! Yes, I think we should add this or something like this. I wonder if we need explicit commands to load/save the history or if we should simply load it at startup and append the current line to the file every time when return gets pressed.
Ahhh, you want to kill my poor iBook's battery!
I guess, I wouldn't bother to save the history if I need to invoke an explicit command.
Are you sure? What if the REPL were considered just like any other file-backed buffer, and C-x C-s saved it, C-x s prompted you about it, and exiting Emacs would ask you if you wanted to save it?
For me, the times I would want to save the REPL are the times I need to shutdown and continue a work session later. Otherwise, I tend to complete the problem before slime is terminated, and have little interest in the REPL history. I suppose a three-state state-variable is required: one state to never save the REPL, one state to always save it locally, and the third state to follow the above suggestion of C-x C-s.
GP lisper writes:
On Wed, 28 Sep 2005 12:10:38 -0700, tfb@OCF.Berkeley.EDU wrote:
Are you sure? What if the REPL were considered just like any other file-backed buffer, and C-x C-s saved it, C-x s prompted you about it, and exiting Emacs would ask you if you wanted to save it?
For me, the times I would want to save the REPL are the times I need to shutdown and continue a work session later. Otherwise, I tend to complete the problem before slime is terminated, and have little interest in the REPL history. I suppose a three-state state-variable is required: one state to never save the REPL, one state to always save it locally, and the third state to follow the above suggestion of C-x C-s.
How would my suggestion be insufficient for how you want to use the REPL history? If you're exiting Emacs and don't want to save the history, just answer no when it asks you if you want to save it. The only time I could see this being a problem is if Emacs itself crashes right after you type something important that you need to save ... at the REPL. Doesn't seem like a problem to me.
On Sat, 1 Oct 2005 01:15:49 -0700, tfb@OCF.Berkeley.EDU wrote:
How would my suggestion be insufficient for how you want to use the REPL history?
It's just a matter of different work habits. I've already saved everything prior to C-x C-c, and when I type that, I expect emacs to disappear and I'm preset to the next move. Getting prompted then is an annoying interruption.
It's clear that for simplicity, your method is better.
* Stefan Kamphausen [2005-09-27 14:01+0200] writes:
If you are interested in using this code in -say- slime.el I'll pass copyright to you (as I state in the header of the attached file). If you prefer to receive a patch to slime.el I can do that, too. Just tell me.
Thanks for the work.
I merged this in with only minor changes:
- the history is saved loaded and saved at automatically, i.e. when the REPL mode is activated resp. a REPL buffer gets killed or when Emacs exits.
- we remove any text properties before saving, because XEmacs can't read them
- changed the default filename to ~/.slime-history.eld
Helmut.
Hi,
Thanks for the work.
Well, I think that should have been my sentence addressed to you, er? ;-)
I merged this in with only minor changes:
Cool.
- changed the default filename to ~/.slime-history.eld
Shouldn't the history size and the filename be customizable? Like:
(defcustom slime-repl-history-file "~/.slime-history.eld" "File to save the persistent REPL history to." :type 'string :group 'slime-repl)
(defcustom slime-repl-history-size 100 "Maximum number of lines for persistent REPL history." :type 'integer :group 'slime-repl)
Especially since there is already a group for the REPL.
Anyway, thanks for considering my contribution.
Regards Stefan
-
Christian Lynbech -
GP lisper -
Helmut Eller -
Marco Baringer -
Stefan Kamphausen -
Thomas F. Burdick