I'm on ubuntu 19.
Using emacs, slime and sbcl to practice some lisp.
Currently I have one buffer in slime mode in one window and the slime-description in the other window.
When I want to execute a line, I write it on the buffer and press C-c C-p.
But when I try to do the same for the line
(defvar *name* (read))
to set the the name var with the user input, nothing is happening.
Why ?
Also I would like to execute the whole script and not one line at a time, how do I do that ?
'Nothing is happening' because read is waiting for you to type something at the REPL. If you look at the REPL you will be confused because the form you are evaluating is not displayed, so all you see is ... nothing, but you need to type something at it. Further, it's not clear from your description what buffers you have displayed, but I suspect the REPL is not one of them, which is going to make things even worse.
I don't know how other people use SLIME, but what I do is to have at least the REPL (the thing you get after typing M-x-slime in one window, and a file I am working on in another. You can then interact with the REPL just by typing at it, and send code to the running lisp from the file with C-M-x or any of the other commands (in particular things like C-c C-k which compiles & loads the file.
However you almost never want a file you are compiling or loading to include anything which causes read to be called at compilation or load time: the results are going to be mysterious to put it mildly: the system will just stop with no prompt waiting for you to type something. It makes much more sense to do that in the REPL:
CL-USER> (defvar *name* (read))
(here is the data I am typing in)
*NAME*
Indeed, even when you go to some lengths to make calls to read non-mysterious in files being loaded, you have to go to yet further lengths to make them safe. Consider this file, toxin.lisp:
(defvar *my-thing*
(progn
(format *query-io* "~&thing? ")
(finish-output *query-io*)
(read *query-io*)))
Now:
$ lisp
[...]
(load "toxin" :verbose t)
;Loading #P"toxin"...
thing? #.(quit)
Of course there are much worse things I could have said than that to the Lisp.
Related
I'm trying to work with Clojure using inferior lisp mode. My setup:
(setq inferior-lisp-program "lein repl")
(run-lisp) ;; Clojure REPL appears then...
When I evaluate short forms using lisp-eval-region, there are not any errors. But, when I try to eval a long region or even entire buffer, I face the following strange behavior:
The input text sent to the REPL buffer is full of rubbish symbols:
(doseq [addr addresses][53G[38G[54G
For unknown reason, some symbols are cut and so cannot be found:
(u/validat (:entity_id obj)[61G[46G[62G Whereas in the code I have (u/validate-access!.
More comprehensive dump is here.
ps: I've been working with cider for a long time, just wondering are there any alternatives.
The "rubbish symbols" are ANSI escape codes for putting the cursor on a certain column. Your REPL process is outputting these, and Emacs's process buffer doesn't know how to handle them.
Notice that in a lein repl when you type a closing parenthesis your cursor will briefly jump back to the opening one, that's what those escape codes do.
You're right that inf-lisp should work, Rich Hickey used it for a long time, maybe he still does. I would try using it with the plain built-in Clojure REPL, instead of with Leiningen's, since the latter really expects an actual terminal on the other end.
(setq inferior-lisp-program "lein run -m clojure.main")
Also consider using inf-clojure, it's very similar to inf-lisp, but is better suited for use with Clojure.
I'm starting to play with CLisp, and therefore Emacs too, including the "SLIME" plugin (or whatever it's called. How is it called?)
So I've been playing with the REPL for quite some time now, and defined a lot of functions in there with (defun).
Unfortunately, none of these functions have been written in a text file, and I don't fancy retyping all that. Is there a way I could dump or otherwise save the work that has been done in the REPL to a file? (bonus points if the file is Lisp source code :) )
SLIME is an elisp program for interacting with Lisp.
There's no simple option to recover functions you've typed only into the repl into a file. function-lambda-expression can sometimes return code, but it often does not.
If the repl is still in a buffer, you could copy the whole thing into a file and then use string or regexp replacement to isolate the function definitions.
It's not too hard to avoid this problem in the future.
Most people work by writing definitions into a file, and then using a key combination to send them to Lisp, bypassing the REPL. I use the C-c C-c combination when the cursor is on a function to compile and load the expression. C-x C-e also works. Then I switch the the REPL to actually use the function.
See also the function DRIBBLE, which makes sure a log is written.
foo:~$ clisp
...
[1]> (dribble "foo.text")
#<OUTPUT BUFFERED FILE-STREAM CHARACTER #P"foo.text">
[2]> (+ 3 4)
7
[3]> (defun bar (baz) (* baz baz))
BAR
[4]> (bar 10)
100
[5]> (quit)
Bye.
Let's look at the file:
foo:~$ more foo.text
;; Dribble of #<IO TERMINAL-STREAM> started on 2015-05-08 21:38:48.
#<OUTPUT BUFFERED FILE-STREAM CHARACTER #P"foo.text">
[2]> (+ 3 4)
7
[3]> (defun bar (baz) (* baz baz))
BAR
[4]> (bar 10)
100
[5]> (quit)
Bye.
The last paragraph in Xach's answer is what it is all about.
When programming in Lisp, typing function definitions directly into the REPL is the wrong way to do it. The right way is to set up your text editor (emacs) so that with certain keystrokes, the expression at the cursor (the entire function definition) is sent to the REPL. Then to invoke a function, you switch to the REPL. This is what SLIME is for.
Strictly speaking, the text in your emacs buffer doesn't have to be written to a disk file, in which case it will be gone after you close the editor. But normally you save it to a file.
You can search through your REPL history for the function definitions. If you have the beginning of an expression already typed in, then SLIME will only cycle through previous entries that begin with the same thing:
CL-USER> (defun
Press M-P from there, and you'll cycle through all the defuns you've typed in.
According to this question, I can customize the variable *DEBUGGER-HOOK* so that it falls back to toplevel (in REPL) instead of the debugger. I've added this line to my ~/.sbclrc and it's all fine when I start sbcl from command line.
(setf *debugger-hook* #'(lambda (c h) (declare (ignore h)) (print c) (abort)))
But, the above doesn't work for Emacs SLIME. Whenever I compile/load a file (C-c C-k), it still invokes the debugger (with options like abort calculation, restart, enter new value etc.). How can I ask SLIME to just print the error message and throw me back to toplevel? Yea, it's with SBCL and the same ~/.sbclrc as before. Looks like SLIME doesn't respect a user's setting of *DEBUGGER-HOOK*.
As per http://common-lisp.net/project/slime/doc/html/Other-configurables.html setting SWANK:*GLOBAL-DEBUGGER* to nil in ~/.swank.lisp file should force SLIME to not replace *DEBUGGER-HOOK* to SWANK:SWANK-DEBUGGER-HOOK (which shows list of restarts etc.), but it somehow doesn't work for me, i.e. SWANK:*GLOBAL-DEBUGGER* is nil but anyway *DEBUGGER-HOOK* is replaced by SLIME. Maybe you'll be more lucky.
As a workaround I can propose to set *DEBUGGER-HOOK* to whatever you want in the slime-repl buffer manually, which is worked for me.
What problem can happen if the goto-line function is used in a non-interactive elisp program? Its docstring gives a warning saying that:
This function is usually the wrong thing to use in a Lisp program.
What you probably want instead is something like:
(goto-char (point-min)) (forward-line (1- N))
Moreover, when I try to byte-compile-file my init file including goto-line, I get a unpleasant warning like this once again:
.emacs:170:19:Warning: `goto-line' used from Lisp code
That command is designed for interactive use only
Is using goto-line in a non-interactive program really so dangerous? Relatedly, why is the suggested forward-line solution preferable?
Firstly, this prevents Elisp programmers from fall into bad habits -- writing
inefficient code in a line-number centric way. i.e. instead of using
(forward-line 1) calculating the current line number, incrementing, and using
goto-line.
From this mailing list article:
In a nutshell, the reason why goto-line should not be a frequently
used command is that normally there's no reason to want to get to line
number N unless you have a program that told you there's something
interesting on that line.
Secondly, goto-line manipulates the user's environment in addition to moving
the point (i.e. push-mark). For non-interactive use, this may not be what
you want. On the other hand if having considered all this, you believe
goto-line is exactly what you need, then just call it like this:
(defun foo ()
(interactive)
(with-no-warnings
(goto-line N)))
And you won't get any compiler warnings.
in addition to what was said:
"goto-line" finally recurs onto "(forward-line (1- line)", which in effect does the work. All other of the 43 lines of "goto-line" command body deal with interactive use. For example considering a possibly universal argument.
When writing a program resp. when running it, your computer is in another state than following an interactive call. Thus you should address this state by using "forward-line" straight on.
I have a confession: I don't know Lisp. Despite that fact, with a bit of help from some co-workers, I managed to write an emacs macro/script which:
switched to shell mode (ie. M-x shell-mode)
disabled truncating lines (ie. M-x toggle-truncate-lines)
started a database console (ie. "mysql")
I was then able to start emacs with that macro using the --script option, and suddenly I had a way to start mysql in a much friendlier environment with a single command :-)
But here's the problem: I changed jobs and left that script behind. Now I'd very much like to re-create that script at my new job, but I no longer have any emacs experts to help me write it like I did at the old job.
Now, I really hate SO posts where someone basically says "please write my code for me", so I don't want to do that. However, if any emacs macro experts could at least give me some pointers (like "here's how you invoke a M-x command in a macro"), or point me to an emacs-macro-writing guide, or otherwise "teach me to fish" on this issue, I would greatly appreciate it.
... and if someone just happened to have a similar script already lying around that they wanted to post, I certainly wouldn't complain ;-)
Most emacs commands (i.e., M-x toggle-truncate-lines) can be translated directly to elisp by wrapping them in parentheses:
(toggle-truncate-lines)
The rumours are true, in lisp you just scatter parentheses around and they make magic.
Now in this case, you can do better. Toggling makes sense for an interactive function, but in a program you don't really want to toggle truncate-lines, you want to turn on truncate-lines. Its the same thing if truncate-lines was turned off to begin with, but you don't know when your program will be run next. Anyways, in Emacs, features are often controlled by a variable. In this case, the variable is truncate-lines, and to turn that feature on, you set the variable to t (which means true).
To do this, use:
(setq truncate-lines t)
We use setq instead of = for assignment, because they made lisp before = had been invented.
For the real scoop you should take a look at Robert Chassel's excellent "An introduction to to Programming in Emacs Lisp". It comes built-in with your emacs, you can get to it with C-h i m Emacs Lisp Intro.
A good way (I think) to start writing elisp functions is to record keyboard macros, and then to analyse them using edit-kbd-macro
For example, if you start recording a keyboard macro using f3, then do interactively all the things you want and terminate the macro using f4, you can see the underlying emacs-lisp commands using M-xedit-kbd-macrof4 (this last f4 is the key binding you'd have used to execute the keyboard macro)
<<shell>> ;; shell
<<toggle-truncate-lines>> ;; toggle-truncate-lines
mysql ;; self-insert-command * 5
RET ;; comint-send-input
Now you can write a script using these functions, looking up the documentation (e.g. C-h ftoggle-truncate-lines) to see if you should call them with special arguments in non-interactive mode.
You should also replace self-insert-command by calls to insert.
This should give you something like the following script, which you can call using emacs --load myscript.el
(shell)
(toggle-truncate-lines 1)
(insert "mysql")
(comint-send-input)
Of course, this might not work as expected the first time, so you might have to eval (setq debug-on-error t) to get debugging information.
What version of Emacs are you using?
In Emacs 24, I have M-x sql-mysql, which does everything you ask and has font-locking.