I have this issue in Emacs - I run cider-eval-buffer and one of my function definitions are void which results in an error (or multiple). I correct the error and run the command again only to get Lisp nesting exceeds 'max-lisp-eval-depth'. I can manually evaluate pieces of code via C-x C-e or C-M-x but I cannot run cider-eval-buffer again or re-evaluate the namespace I am working in. Any thoughts?
I'm cider's maintainer. Please, report this as a bug here, together with some example code that can be used to reproduce the error and your cider & emacs versions.
Related
I am coding in fortran90 on Emacs (no-windows mode) with fortran-mode. I have only used Emacs for Python for which it works without problem but now that I have switched to fortran90 I have many little issues that I don't know how to configure.
The biggest problem I have is with the commenting region command. I usually use M-; to comment regions but I get something like this:
c$$$ if (x1.eq.0) then
I know about the command
C-x r t
which actually does the trick (I can insert a ! at the beginning of each line) but I am so used to the M-; command and I wish I could keep using it. Also, with the latter command I can comment and un-comment the region.
So what I want to do is to replace the symbol for commenting in (and only in) fortran-mode. And such that it works every time I open/close Emacs with fortran-mode.
Thanks!
I haven't coded in Fortran for the last 30 years (!), and I'm not acquainted with Fortran mode in Emacs. But looking at library fortran.el I see that there are some user options for customizing comment behavior. Take a look at them by using M-x customize-group fortran-comment. The doc for each should be self-explanatory. If not, more info is available in the Emacs manual -- see node Fortran and its subnodes, in particular, node Fortran Comments. It specifically talks about M-; in the context of Fortran mode, for instance.
In nREPL, the user could simply C-x C-e to evaluate the preceding form in the running REPL.
However, in Cider, it seems there is only a way to evaluate the form in the echo area or a popup buffer.
Is this really the case?
Please someone correct me, because this is a useful feature to lose.
I'm using nREPL and by default evals to echo area.
If you want to send the C-x C-e output to the running repl you can use both solutions on this question which are working quite fine for me.
I'm cider's maintainer and I can assure you C-x C-e's behaviour hasn't changed in quite some time. I'm also absolutely certain nothing was changed when I renamed nrepl.el to cider some time ago. I'm OK with implementing such feature if you need it, though. Just open a ticket on the issue tracker.
C-c M-e which is bound to cider-eval-last-sexp-to-repl will get the job done. My cider version is 0.16.0.
I have a small GTK python application that imports a package (Twisted) that may not be loaded twice.
If I run my application in emacs with python-mode.el and press C-c C-c, the application gets executed in a python shell window.
If I now close the application, the python shell stays up and running. If I now press C-c C-c again, emacs "reuses" the old python process and thus I run into problems because I'm installing a Twisted reactor twice.
Is it possible to have python-mode.el open a new shell window each time I execute a buffer?
python-mode.el comes with a command py-execute-buffer-dedicated,
opening a new and reserved process for it
In python.el, a new inferior process is launched in a new buffer if the python-buffer variable is set to nil. Therefore, it's possible to advise the python-send-buffer function to reset that variable to nil after every invocation, thereby forcing a new Python process to be executed for every subsequent python-send-buffer command. Something like the following should work:
(defadvice
python-send-buffer
(after python-send-buffer-new-proc activate)
(setq python-buffer nil))
(ad-activate python-send-buffer)
I know that your post was asking for help with python-mode.el, but I thought it might be helpful to mention this anyway, as I'd surprised if python-mode.el doesn't use a similar mechanism. If I have time, I'll try to look into it.
Edit: the python-mode.el package uses the command py-shell to initiate a new inferior Python process. I found a mailing list posting in which a user provides an ad hoc function that appears to do what you need.
By the way, it might be worth considering that trying to alter the default behavior of python-mode isn't the best approach to this problem. I don't know what your code does, and I'm not particularly familiar with Twisted, but it seems to me that experiencing major errors when evaluating your code a second time within the same session could be a sign of a more fundamental design problem. I fail to see how it could be a matter of multiple imports of the same module being the issue, as Python modules are only loaded once, with successive import statements having no effect (for that, an explicit reload or execfile() is required). If I'm completely off-base here, I apologize, but I felt this possibility might merit mention.
I installed ClojureBox and the REPL is not working.
If I type (+ 1 2) into the *slime-repl clojure* buffer and press enter, the expression text becomes bold as if it has been evaluated, but there is no result of the evaluation printed on the screen.
Can anyone help me figure out why my REPL is not printing the evaluation results?
Thanks.
Try looking in *inferior-lisp* and failing that all other buffers.
The binding of clojure's *out* plus emacs slime-swank based capture and redirection of output streams can occasionally make it seem like emacs is swallowing output. (This can get really confusing when output comes from multiple threads - definitely one of the few warts of developing clojure with the slime-swank environment.)
Have you ever tried emacs before using clojurebox? Any left behind .emacs configuration or library paths etc. can interact badly with clojurebox which, in my experience, assumes it is the only installation of emacs going onto a clean system.
I'm having a problem with an Emacs lisp package that I pulled down from the ubuntu distribution. The package is JDEE, and it complains of Args out of range: "63", 0, 4 in the mini buffer and the *Messages* buffer whenever I open a file. This bug appears to have been reported last September but no action has been taken. I'm not an emacs newbie, having written some Elisp code myself, but I've never attempted to debug anything like this. I would like to stop the file load in a debugger when this error happens to at least get an idea of where the problem is coming from. I've read section 18.1.1 of the Elisp manual on "Entering the debugger on error" but trying to load the file after playing with various combinations of values for debug-on-error, debug-ignored-errors, and debug-on-signal appears to have no effect. Has anybody got any suggestions for my next step?
If debug-on-error isn't working, I'd start with the source itself. Find the keybinding/event that is causing the problem, and locate the function.
C-h k <keystrokes>
M-x find-function <function-name-from-above>
Now, once you are at the source
M-x edebug-defun
And the next time you hit the key, you should be able to step through the program. At that point, you can see which portion causes an error - and drill down that way.
You can also try setting the variable 'stack-trace-on-error to see if you can find the culprit (though 'debug-on-error usually works for me, not sure why it doesn't for you).
As a last resort (if edebug-defun doesn't work), you can redefine the routine with a call to (debug) in it, sort of does the same.
I suppose JDEE is somehow inhibiting debug-on-error. Perhaps grep through its files for the error message "Args out of range". While debugging, make sure to load the uncompiled .el files, not the byte-compiled .elc files (you will notice it in the debugger if you are running byte-compiled code) by entering commands like (load "foo.el") instead of (load "foo").
I got the same error when using find-grep after accidentally redefining (current-time-string) in one of my own scripts.
Using the M-x edebug-defun tip posted above I managed to find the issue when I stepped through the code giving the error seeing the call to (current-time-string).
Not sure how helpful this is in your case.