How would you automatically "record" a slime repl session? By "record" I probably mean to auto-save what the repl buffer has, similar to any code buffer's auto-save. I'm sure "state" would be a much tougher issue, but at least to save the buffer contents would be a start. Of course I could just do a save C-x-s and name it something like repl20131115-111034.srepl, but to have a behind-the-scenes auto-save capability (including timestamp in the file name) would be nice.
Psychotherapy
I asked this question about Lisp 20 years ago, about R a year ago and I am not asking it about python now. So, let me try to answer it.
What you asked for
Timed Logs
You certainly do not want the automatic repl-timestamp.log files - they will fill up your disk and you will never actually look at them.
Auto Save
Yeah, you can save the lisp interaction buffer into a file (and then the buffer will be auto-saved periodically), but you do not want that either.
You are much better off typing your code in a buffer associated with a lisp file and sending it to the lisp interaction buffer, and only copying the "interesting" lisp output back to your file buffer. E.g., you do not want to save all 42 bad versions of a function, just the working one (and maybe a few intermediate ones - but you have git and hg for that).
What you really need
What you really want it two things:
Remember what you did
Restore the state where you left off
Here is how to do that:
Remember what you did
You can use dribble to save into a file both what you type and what Lisp replies.
This is useful, however, I think I examined only very few of the zillions of dribble files I created in my newbie days.
They are there mostly for your peace of mind.
Restore the state
This is what lisp images are for: they write to disk the "state of the lisp universe" so that you can start from where you left off.
Related
as the title said, I am learning common lisp right now and using portacle, following Practical Common Lisp by Peter Seibel.
I found it quite annoying that the Slime-repl-sbcl buffer keep the writing at the end of the screen (using C-l or C-v doesn't help since once I try to execute an expression it will roll back to the end of the screen)
Is there anywhere to improve this? (should I just write on a text file and compile it? the only similar subject I found was about Cider repl and couldn't understand it, since I am still new to lisp)
Thank you for your time
I would like this fixed too. No solution yet. In slime-repl.el, I found:
scroll-conservatively (variable):
A value of zero means always recenter point if it moves off screen.
my test wasn't conclusive.
slime-display-output-buffer (function), which calls slime-repl-show-maximum-output, which role is to
Put the end of the buffer at the bottom of the window.
I rewrote slime-display-output-buffer without this call, but that wasn't conclusive either.
Maybe I tested badly.
(I'm making this answer a wiki)
You would indeed typically write in a source file, and compile each expression separately. Use the REPL only to test functions or do simple computations. To compile functions (or really, any toplevel expression), use C-c C-c - bound to slime-compile-defun by default - when the point (= your cursor) is inside the function's code. The REPL will then "know" of it, so you can test it there, but as it is now written in file, you can also modify it without having to copy/paste anything ! Just make sure to recompile functions that you modify !
If you want to compile/load entire files at once, look at the other compilation commands, e.g. slime-compile-and-load-file (see the SLIME manual, and its Compilation section)
For your problem: there is Emacs variable, named comint-scroll-to-bottom-on-input (or something along those lines, can't remember exactly ...) which enables the behaviour you are seeing, so that you don't have to scroll back to enter new expressions. It is possible that SLIME has another variable which configuring this behaviour for its REPL; in that case, it would probably be named almost the same, and you can set it to nil to disable it.
Finally, don't hesitate to look at the other tools provided by SLIME ! For example, it comes with an "inspector" (see the relevant section), that you can use instead of evaluating expressions such as *db* in the REPL. In that simple case, it makes no real difference, but if you start having - say - hash-tables or different structures/classes, it becomes an incredible tool for interactive development, to examine the internal of almost everything, redefine things directly from within the inspector without needing complex accessors, and so on.
I am using emacs 23 on two computers.
On both, dpkg -s emacs outputs the following version number.
However one has window.el and the other not. This make some function such as split-window behave differently. The help page of this function on the computer that apparently has not window.el installed reads that it comes from C source code instead.
Where does this difference comes from?
I prefer the behaviour of the one that says that split-window comes from window.el: it allows to specify the SIDE when splitting window and provide additional function such as window-resize.
I suppose this is the most recent one but I do not know how to check it nor how to upgrade the other to this state.
Library window.el is as old as the hills. Perhaps you meant that one of your Emacs installlations has window.elc but not window.el?
More likely, you are referring only to function split-window. Yes, it used to be a built-in function (i.e., defined in C), and now it is defined in window.el (which file exists also for the older Emacs versions where that function is a built-in).
FYI, lots of window and buffer-display stuff was changed around the same time as split-window was rewritten in Lisp. Lots of behaviors changed, in minor or major ways.
What is not at all clear is what the problem is that you are reporting. You ask, "Where does this difference comes from? How to fix it?" I've explained a bit about the difference. As for how to fix it -- what is the "it" that needs fixing, and what would the fixed behavior be like?
IOW, your question is, so far, unanswerable. If you specify things more exactly, perhaps we can help more.
I'm not certain what's going on with your debian packages, but if memory serves the readable .el(.gz) files are not supplied in the basic package, but in a separate package. This is because all you strictly need is the byte-compiled .elc files, so they can reduce the base package filesize by omitting them (at the expense of enabling you to read the elisp code).
Is M-x load-library RET window RET successful?
Note that Emacs 24 is the current stable version. You might want to upgrade.
Edit:
M-x emacs-version tells you which version of Emacs you're running, which will always give you a definitive answer.
(And if the versions are identical, then run emacs -Q to eliminate and site- and user-specific config files from the picture, as those are always a likely culprit for differing behaviours.)
I was reading this question and the answers are a convoluted mess (timer function REALLY?)
In any case, I don't care about recreating these buffers, as that is trivial. But these buffers contain information which should never be deleted, and because they don't have associated filenames, they are usually killed without confirmation.
I do have a solution in mind, but I want to see if someone has a more "canonical" one.
jtahlborn provided the most canonical solution, except the "keep-buffers" package is showing its age has some issues:
You had to specify whether all protected buffers are to be buried and erased (erased buffers can be recovered with `undo') when killed, or just buried when killed.
member is reimplemented as find-in-list less efficiently.
Helper functions that didn't really help.
I made the the protected-list an alist that associates regexp to erase-action, and deleted the useless (IMO) code. By default, "scratch" is erased when killed, "Messages" is never erased or killed.
See github
You can try adding a function to the kill-buffer-query-functions variable that checks the current buffer, if it is scratch or Messages then return nil. I've never tried this before but it should prevent them from getting killed.
Edit: Here's an example of using kill-buffer-query-functions that allows you to protect specific buffers: http://www.emacswiki.org/emacs/protbuf-by-name.el
i use the keep-buffers utility.
In addition to what has been said by others --
*scratch* is in no way a "vital" buffer. And by default nothing and no one automatically writes anything to *scratch* or modifies anything there.
(FWIW, I tend to use an ordinary Emacs-Lisp mode file buffer instead of *scratch*. One reason is that I do typically want to save it at some point. (Another reason: I prefer that C-j do what it does in Emacs-Lisp mode. Yes, I could change just that key binding, but instead I keep *scratch* for some kinds of interaction, but typically not for a coding sandbox.)
*Messages* is a different story.
But how are you accidentally deleting *Messages*? In decades of using Emacs I don't think I've ever accidentally killed *Messages*. What's the scenario to produce the problem you are looking for a solution to?
for those who don't know, imenu is a thing in emacs that lets a mode insert one or more menu items into the menu bar. The most common usage is to make a "table of contents" accessible from a drop-down menu, so the user can quickly jump to declarations of functions or classes or sections in a document, etc.
imenu has a couple different ways of working - in the first and more commonly used way, a major mode provides regexps to imenu, and imenu uses those regexps to perform the scan of the buffer and build the index. A major mode sets this up by putting the list of regexps into imenu-generic-expression. The second way is for the major mode to perform its own scan. It can do this by instead setting the variable imenu-create-index-function to the name of a function defined by themode, which returns a list containing the table of contents.
I'm doing the latter - imenu-create-index-function - but sometimes the fn takes a looong time to run, say 3 or 4 seconds or more, which freezes the UI. If I make the operation asynchronous, that would solve that problem.
I know about asynch processes. The scan logic is implemented in elisp. Is it possible to run elisp in an asynch process? If so, how?
Or, is there a way to run regular elisp asynchronously in emacs, without resorting to an asynch process?
I think the way font-lock does it is, it fontifies on idle. It keeps state and fontifies a little at a time, always remembering where it left off, what else needs to be fontified, what has changed since the last fontification run, etc. Is my understanding correct? Maybe I could use this incremental approach .
Recommendations?
To run elisp asynchronously you can use either run-with-idle-timer or run-with-timer. I imagine you'll want the idle version. Check the documentation links for more details.
Note: If the code takes 3 or 4 seconds to run, it'll still take that long (and freeze your Emacs while it runs), so if you can break the work up into small enough chunks that it only takes .5 seconds or so at a time, that might work well.
One package that I use all the time, pabbrev.el, uses idle timers really well - I never notice it running. That might be a good package to examine to see how it breaks up the work (it is scanning all open buffers and building up a word frequency list).
The answers posted by TreyJackson and jeremiahd were valid back in year 2011. Now, in 2018, here is a link to the emacs documentation for asynchronous processes.
You can run elisp in an asynch process by spawning emacs in batch mode as the process, see http://www.emacswiki.org/emacs/BatchMode . Other than that, there's basically nothing as far as I know.
It looks like http://nschum.de/src/emacs/async-eval/ basically wraps the boilerplate necessary to do this. No clue if it's actively maintained or anything though.
When viewing piped output to Less, sometimes I'd like to be able to view it in Emacs in order to get syntax highlighting and use emacs commands for searching, marking, copying, etc.
I see that Less has a v command that can be used to open the currently viewed file in $EDITOR. Unfortunately this doesn't work when viewing piped input.
Also, I don't know how to get Emacs to display stdin as a read-only document.
So, is it possible to set up Less with something like v but that pumps the current buffer into Emacs as a read-only file?
Thanks.
If you scroll down in http://www.emacswiki.org/emacs/GnuClient, you'll come to a section titled "Piping data to an Emacs buffer" which may be relevant. Or you can hack up a solution involving emacsclient and temporary files. (link dead).
I found another variant while looking for a duplicate of the dead link: Piping to an emacs buffer with emacsclient which points at code stored on github.
I've formalized the solution here: github e-sink