I am not meaning cleaning up the text output of REPL; I mean cleaning up all evaluated results in REPL. During developing, repeatedly C-c C-q and C-c M-j is low efficiency.
UPDATE
There may be some bad debug behaviour of mine. I am not sure how other people develop progs with CIDER, but I really need the functionality mentioned above. I guess other developers also encounter same problems as mine.
For example, at the top of a clojure prog unit, I use declare to declare a function foo, which is used by another function bar, and foo is implemented after bar. Then, I C-c C-k, etc, and the prog goes well. Later, I removed the forward declaration of foo occasionally. What does happen? The prog still goes well. REALLY? Then, I commit my whole job and terminate the CIDER REPL session happily.
Disaster on morning: Symbol foo not found!
That's my story. So, nobody has ever encountered similar problems?
Try the (refresh) function in the clojure.tools.namespace.repl namespace:
The refresh function will scan all the directories on the classpath for Clojure source files, read their ns declarations, build a graph of their dependencies, and load them in dependency order.
https://github.com/clojure/tools.namespace#reloading-code-usage
It doesn't seem to remove the vars declared in the user namespace, which I've typed into the REPL, but it does:
...unload (remove) the namespaces that changed to clear out any old
definitions.
We generally add that plus a few other useful things to the user namespace, so it's loaded into the REPL on startup:
(ns user
(:require [clojure.tools.namespace.repl :refer [refresh]]
[clojure.repl :refer [doc source]]
[clojure.pprint :refer [pprint pp]]
[midje.repl :as midje]
[clojure.stacktrace :as st]))
To keep that code separate from your main and test sources, put that in a file at <project root>/dev/user.clj, then add the following to your lein project.clj file:
:profiles {:dev {:source-paths ["dev"]}}
(p.s. although it's not the question you want answered, for those seeing this answer and wanting to clear the text in the Cider REPL, it's C-c M-o (https://github.com/clojure-emacs/cider)
In EMACS when I works with Clojure in cider-mode, I use:
C-c M-o in the repl buffer
it is bound to cider-repl-clear-buffer
Like others have already pointed out, the 'proper' solution is to use Stuart Sierra's component library.
But since you're running in CIDER, you can use C-c C-x to run cider-refresh, which will reload your project and thereby recreate your initial state.
If you're dealing with a large number of things which have state which you want to clear to have a clean developing environment you might consider doing one of the following:
1.) Reassess your design and see how much of that state is actually necessary. In many situations you might be using atoms, refs, or other stateful items unnecessarily and if you adopt a more functional approach, you won't find yourself needing to clear up your development environment as often.
Presuming legitimate reasons for using state:
2.) You can wipe out a namespace and all of it's contents by using the clojure function remove-ns: e.g. for a namespace called user.fancy-namespace you can clean the NS out by running (remove-ns 'user.fancy-namespace') and then simply re-evaluating the namespace. This works well for cleaning up a single namespace, but if the stateful items you need cleaned are in other namespaces, it can get tedious to do this for every namespace involved.
3.) Stuart Sierra's component library was designed to manage components which involve state. Very useful for managing DB connections, memcache clients, etc, but will require a re-architecting of your project in order to make full use of it.
As mentioned by others, it is only necessary to clear the repl if you have variables which are holding state information. For non-state carrying components, just reloading the source buffer (re-evaluating it) is sufficient.
One very interesting way to manage a workflow which does have components that track state is Stuart Seirra's component framework. See http://youtu.be/13cmHf_kt-Q
Another approach is to write your code using defonce rather than def, which will allow you to reload your source code without redefining state variables.
If on the other hand, you want to do this to clean up defn or defmacro definitions you don't need i.e. clean out 'polution' from your repl, then to be honest, I wouldn't bother. If nothing is calling a defn or macro, it really doesn't matter.
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 new to Emacs Lisp and the feeling is like it lacks strictness (and namespaces, and more...).
To be more comfortable with it I need a
way to make interpreter/byte compiler complain a lot if I use deprecated or obsolete function or variable (even better - hide them). Why this is not looks so simple and removing corresponding .el packages will not work is obvious - they may be needed by some legacy code.
Also, if it is possible, turning off all aliases would be nice. In my opinion they are there only for backwards compatibility, which I do not need. Because of setting this one globally can ruin something, I hope there is something like use strict in JavaScript, which can be applied to the inner body, so the effect is neatly localized.
Do not get me wrong, I think that global namespace of the Elisp is like a dump and if it could be any cleaner, why not?
To put in one sentence: how to make Elisp global namespace obsoleteless and deprecateless, as slim as possible?
I don't know of an Emacs Lisp linter that is built in to Emacs.
I do two things for my own code to try to ensure some level of cleanliness.
First, I make sure that byte-compiling the code doesn't give any errors or warnings. The byte compiler does a certain amount of checking.
Second, I enable lexical binding. This lets the byte compiler detect a few more possible warnings.
This is about the best you can do with the built-in tools. If you want to go further you could write your own tree walker to perform whatever other tests you like.
I constantly find myself doing multiple manual (require '[my.lib :as foo]) right after I start cider with M-x cider-jack-in in my clojure projects. I suspect there must be a hook to run some code on a successful connection. Is there? The alternative would be to put all requires in an external file and just (use 'that.namespace) but lazy as I am, I want to even skip that step if possible.
UPDATE:
Putting the forms in .lein/profiles.clj :injections is fine as long as one uses them exclusively in the Repl (as per lein repl). To make them available from the nrepl in emacs one must use the second solution named by arrdem below.
Here is some more comprehensive info.
Leiningen's :injections feature is the cannonical way to pull this one off. Once Lein boots a Clojure instance, the code in :injections gets evaluated allowing you as you say to populate the user namespace with libraries that you use all the time.
Another approach is to (ab)use the file user.clj by adding a :dev profile with a dev-only source path that "happens" to contain a user.clj with preloading code in it. This is done in Grimoire with the file dev/user.clj which serves to create some utility functions in the REPL.
I am byte-compiling a module. It gives me this warning:
Warning: cl package required at runtime
Why is this a warning? I am well aware that I am using the cl package. In fact there is a (require 'cl) statement in the module.
Is there something wrong with using the cl stuff?
If so, is there a list of published workarounds? The main things I use are mapcan and delete-duplicates.
The reason of this warning is a GNU policy which does not want a package cl to be used in Elisp. But it would be foolish as well to prohibit it completely. So they decided to show a warning.
You can find more information here
Just in case someone reads this on his quest for proper use of cl: The methods described here are now deprecated.
As least as of emacs 24, instead of cl you should use cl-lib or, if the macros suffice, cl-macs. These are new versions of cl that work with a clean namespace. E.g. instead of defun* you have cl-defun.
The old cl-package now is only for backward-compatibility and shouldn't be used in new code.
There are namespace clashes between Elisp and Common Lisp but the cl package gets round them by appending an asterisk to the repeated names. For instance it implements the Common Lisp version of defun but calls it defun*. The upshot is that there are no namespaces clashes between cl and Elisp and it is quite safe to (require 'cl).
If you want to get rid of the silly warning, customize the variable byte-compiler-warnings.[1] This will turn off the warning when you compile the code. If you distribute the code the warning will probably came back when someone else compiles it. If you don't want this to happen use the code:
(with-no-warnings
(require 'cl))
You can stop the byte compiler warning about any Lisp form in a similar way.[2] It's probably a not good idea in general, but you may be able to justify it in this case.
The code:
(eval-when-compile
(require 'cl))
will get rid of the warning, but you will only be able to use the macros from the package if you do this. Macros are evaluated at compile time and Elisp does not need to know about them at run time. If you only use the macros from any package, not just cl, then it is a good idea to use eval-when-compile as it will stop unnecessary packages loading at run time, both saving memory and making the code faster. But it seems to me that it's a misuse of the function to use it just to avoid a warning. And, of course, if you do want to use any of the functions from cl, you can't use eval-when-compile anyway.
[1] You may need to add (require 'bytecomp) to your .emacs file to get access to this variable.
[2] In theory, anyway, but there's a bug in with-no-warnings that means it doesn't supress some warnings about lexical variables.
Common Lisp has lots of namespace clashes with elisp, often the functions seem to do the same thing, but differ in some subtle detail. Mixing the two is a risk that is best not done behind the user's back. For this reason, most of the more useful functions in cl.el are defined as macros, so that cl.el can be required at compile time only, and the macros will then only affect the code that uses them in future sessions of Emacs.
I wasn't able to suppress this message after reading the comments before mine.
However, I received the following instruction from a kind person on the GNU emacs mailing list:
Require cl-lib, and then change the call to use cl-remove-if-not,
instead of remove-if-not.
Which proved to be the remedy.
In sum: by 'requiring cl-lib, one must also change the name of the function/macro call.
HTH....
I'm currently in the process of adding functionality to an existing J2EE webapp, in a Tomcat container, and I'm writing my additions using Clojure. My setup is simple: I just add calls to static methods generated by clojure, and code all the hard work from the clojure side. The build process consists in compiling clojure code (lein uberjar) and then compiling the java code with that jar on the classpath.
In the webapp init, I have a call to a generated class that fires up a swank server with a (swank/start-repl). I'd like to be able to connect my Aquamacs' slime to that server, and work interactively from there (up to a point, I won't try nothing that requires a java-side recompilation). But I have a situation that I don't quite understand. If I do a \M-x slime-connect, I get a REPL prompt (after being notified that there's no inferior lisp process, which I think it's ok, since the inferior lisp process is running outside emacs control). I can evaluate forms perfectly, and I can even inspect things like my.own.namespace/my-var. However, if I visit a file with an already compiled clojure code, I can't seem to make slime recognize it as its source. Consider a simple clojure file:
(ns my.namespace
(:gen-class
:name my.namespace
:methods [#^{:static true} [testFunc [] void]]))
(def *secret* "shhhh")
(defn -testFunc []
(println (str "our secret is: " secret)))
Assuming that this was compiled and included in the uberjar loaded by the webapp, I can eval/inspect my.namespace/*secret*. But If I try to eval inside the code buffer, Slime thinks I'm on the user namespace (which can even make sense!). But now I'm left with a single working option - I have to evaluate - one by one, all the forms in the file! \C-c \C-l (loading the source file) won't do nothing - apparently just returns nil and outputs nothing else. Compiling everything seems to do just that - it compiles, shows errors if it finds them, but won't change my namespace. And the strangest is the \C-~ (sync package and directory), which using Common Lisp it does just what I want, but here it freezes the clojure REPL for good.
There's always the option of switching to the REPL, typing (in-ns 'my.namespace), and then all works properly. But that simply isn't practical enough when the clojure files are growing in number (as the namespace of the code buffer won't change automatically!)
My question is, then, whether I'm lacking a basic command/configuration - or if there's an obvious reason for this behavior to happen as such.
I may be misunderstanding your problem, but can't you (while visiting this hypothetical buffer in emacs), hit C-c C-k to compile the buffer in your current Clojure instance (what Slime is connected to)?
Then, in the Slime buffer, switch to this namespace with a (in-ns 'my.namespace). Then you should have access to what you compiled in that namespace.
Switching namespaces automatically on compile has never been the default for swank-clojure, though it might be an optional slime feature that happened to work with Clojure. But C-c M-p to switch the repl to the current buffer's namespace has always worked for me, and I've never heard of anyone having trouble with it.
Are you running on the latest stable versions of clojure-mode and slime-repl? Do you have swank-clojure.el installed? (You shouldn't need it.) It sounds like this could be due to mismatched versions of the elisp libs. If that's not the problem it could be an Aquamacs bug; swank-clojure is designed to work with GNU Emacs. It could also be a bug in slime if you are running from trunk rather than the latest elpa release.
I've just found out that removing the culprit for this issue: slime-redirect-inferior-output, from slime-repl.el, was being called from a hook I had setup. It turns out that it doesn't play well without an inferior-lisp-process (read, a swank server started from within emacs).
So a quick workaround hack is just to remove the error form from that function, like this. Now the hook proceeds, and the namespaces are automatically calculated. As intended. Thank you for the suggestions, nevertheless - they led me to this solution!