I am wrote the code with bugs.
Example:
(print (/ 1 0))
I am trying compile with C-c C-c.
And catch the error with stack frame.
I want see line in the code where an error occured. Clicked 'v' on line in stack frame and catched error.
Error: Cannot find source location for: #<COMPILED-CODE-LOCATION
(SB-C::VARARGS-ENTRY /)>
How can I go to the line in my code?
Screenshot:
As you can see from the error, the line you want to jump to, is somewhere in package SB-C, which is part of SBCL. If you don't have SBCL sources (you've installed a binary or deleted them), you should get them (relevant to your current SBCL version) and then link them up in .sbclrc like this (according to http://www.cliki.net/SLIME%20Features):
(setf (logical-pathname-translations "SYS")
'(("SYS:SRC;**;*.*.*" #P"/opt/sbcl/src/**/*.*")
("SYS:CONTRIB;**;*.*.*" #P"/opt/sbcl/contrib/**/*.*")))
Or just compile SBCL from source and it will know, where they are.
Do you have (proclaim '(optimize debug)) above that line somewhere? This function will ensure that your system has all the debugging data it can get.
Related
I am trying to use flymake in emacs for my .tex file editing.
I've got it all up and running up until I type in an unbalanced brace { or }. When flymake kicks off, it comes back with the error:
Flymake: Configuration error has occurred while running (pdflatex -file-line-error -draftmode -interaction=nonstopmode /home/matt/test_flymake.tex). Flymake will be switched OFF.
For completeness, here is the relevant part of my .emacs file:
(defun flymake-get-tex-args (file-name)
(list "pdflatex"
(list "-file-line-error" "-draftmode" "-interaction=nonstopmode" file-name)))
Looking at the flymake manual gives a hint of what is happening:
CFGERR : Syntax check process returned nonzero exit code, but no errors/warnings were reported. This indicates a possible configuration error (for example, no suitable error message patterns for the syntax check tool).
So, digging into the log (flymake-log-value = 3) I find that the issue is with running pdflatex in that the parser returns a non-zero exit code, but doesn't generate something that flymake recognizes as an error. Specifically:
parsed 'Runaway argument?', no line-err-info
parsed '{Conclusions \bibliographystyle {plain} \bibliography {ma\ETC.', no line-err-info
parsed '! File ended while scanning use of \#xdblarg.', no line-err-info
parsed '<inserted text> ', no line-err-info
parsed ' \par ', no line-err-info
parsed '<*> /home/matt/test_flymake.tex', no line-err-info
parsed ' ', no line-err-info
parsed '! Emergency stop.', no line-err-info
parsed '<*> /home/matt/test_flymake.tex', no line-err-info
parsed ' ', no line-err-info
parsed '! ==> Fatal error occurred, no output PDF file produced!', no line-err-info
So, pdflatex gets mad about my "runaway argument" but doesn't generate something that flymake recognizes as an error. Digging into the flymake.el file shows that flymake-err-line-patterns has this pattern in it:
("\\(LaTeX \\(Warning\\|Error\\): .*\\) on input line \\([0-9]+\\)" 20 3 nil 1)
So... the final issue seems to be that flymake doesn't recognize Runaway argument? as an error message.
Now, my question is: Am I missing something? I can't be the first person to run into this problem but I was unable to find anything about it. I find it hard to believe that everyone just builds a custom solution to modify the error pattern, especially since I'm not doing anything unusual and am just trying to get this to work out of the box.
In case it matters, I am using emacs 24.3 on Ubuntu 12.04 and running pdflatex (pdftex) 2012.
What am I missing? Thanks all for any suggestions you can provide.
Well, I'm guessing 13 views in 3 days means it's unlikely I'll get an answer, so here is what ended up working for me...
Like most emacs issues, this can be fixed by editing your .emacs file. Add this block to your file:
(add-to-list
`flymake-err-line-patterns
'("Runaway argument?" nil nil nil)) ; fixes unbalanced braces in LaTeX files
and this should fix the issue for latex and pdflatex.
Note that (pdf)latex doesn't list give a line number when this error is produced (which is what the nil nil nil represents), so if this happens then flymake will tell you that the error is on the first line of your .tex file.
M-C-f (forward-sexp) and M-C-b (backward-sexp) will skip over balanced parentheses, letting you search for unmatched ones. source
Just for completeness, here is how flymake is checking my .tex files:
(defun flymake-get-tex-args (file-name)
(list "pdflatex"
(list "-file-line-error" "-draftmode" "-interaction=nonstopmode" file-name)))
If your syntax checker is different, or produces a different error message, then swap out the "Runaway argument?" text with your checker's error message.
What I'd like that to do, is when I'm on a line of source such as: foo
And I hit a "jump" key, it should match href="foo.html" and open the file c:/project/root/templates/foo.html.
I've found jump.el (package 'jump' in emacs 24) and am trying to get defjump to work:
(require 'jump)
(defjump
'my-follow-ref
'(("href=\"\\1\"" . "templates/\\1"))
"c:/project/root/"
"Follow a logical link from one part of the source to another.")
My code is based on the example in the help, but I'm getting stuck on a pretty basic emacs lisp error:
mapcar: Wrong type argument: listp, quote
What am I doing wrong?
There is no jump.el in the emacs 24 source tree, and google is no help, but, I guess, your problem is unnecessary quoting: defjump is probably a macro.
Chances are this will work:
(defjump
my-follow-ref
(("href=\"\\1\"" . "templates/\\1"))
"c:/project/root/"
"Follow a logical link from one part of the source to another.")
So, way back in January, I went here:
http://emacsformacosx.com/
I downloaded Emacs and have been using it on my Mac and I like it. I've started trying to get into Elisp programming. To learn more, I'd like to look up some functions. So for instance I do:
C-h f
and then type "scroll-down"
This gives me the following text:
>scroll-down is an interactive built-in function in `window.c'.
>
>It is bound to <kp-prior>, <prior>, C-1, C-x C-1, M-v.
>
>(scroll-down &optional ARG)
>
>Scroll text of selected window down ARG lines.
>If ARG is omitted or nil, scroll down by a near full screen.
>A near full screen is `next-screen-context-lines' less than a full screen.
>Negative ARG means scroll upward.
>If ARG is the atom `-', scroll upward by nearly full screen.
>When calling from a program, supply as argument a number, nil, or `-'.
And the text "window.c" is a link. So I click on the link and I get:
find-function-C-source: The C source file window.c is not available
I'm getting this error a lot while doing a lot of different things. Where do I find the right path, and how do I tell Emacs what that path is?
I did just recently install some ELPA packages, so maybe one of them is causing some chaos?
The variable source-directory will point to the location where the C sources are. If you have a separately downloaded copy, you'll have to point this variable to that directory.
Most packagers don't include the sources, or split them off into a separate package. Install the sources (and maybe tweak an init script to tell Emacs where you put them, if it's not the default location. The pertinent variable is find-function-C-source-directory).
If you didn't manually build Emacs from the source code and patch the C source code, value of source-directory or find-function-C-source-directory would be wrong.
You can manually download Emacs source code, unpack it somewhere and set above two variables accordingly like following
(setq source-directory "/path/to/your-emacs-repo")
;; OR
(setq find-function-C-source-directory "/path/to/your-emacs-repo/src")
GNU Emacs source code and development is hosted on savannah.gnu.org. You can find all the tags here and download the one that matches your M-x emacs-version.
Our work area start with /proj/. On trying to view any directory deep inside /proj , the emacs throws up this error:
ERROR: Opening input file: No such file or directory, /proj/.dir-locals.el
This is 'GNU Emacs 24.0.93.1' compiled from emacs-24.0.93.tar.gz 29-Jan-2012
So two questions:
1. What is the /proj special handling that emacs has. May be it's some nice feature !
2. How can i suppress the /proj special magic for my case ?
WORK AROUND FOUND
(set-variable 'enable-local-variables ())
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.