I started an online course which requires using emacs editor with oz language. OS - Windows 7
when i feed the code, it seems as if the code is compiled correctly but nothing is showed in the emulator window.
In the messages buffer i get the message:
Error during redisplay: (jit-lock-function 98) signaled (wrong-type-argument markerp 1)
any ideas?
I changed my system path from c:\mozart2-2.0.0-alpha.0+build.3777.4c64bf5-x86-windows\mozart\bin to c:\mozart\mozart\bin and similarly for Emacs (removed all Unicode characters in the path as suggested in the course wiki).
Related
I have met a problem about Flycheck in ESS mode(Emacs Speak Statistics). Whenever I open a R file, an error occurs, that is, "Suspicious state from syntax checker r-lintr: Checker r-lintr returned non-zero exit code 1, but no errors from output: error in library(lintr): there is no program called lintr ".
But from https://github.com/jimhester/lintr, he says "lintr is fully integrated into flycheck when using ESS". My Flycheck version is 0.25 and ESS version is 15.09, both are the latest ones!
I reinstall ESS but the error remains. Finally I have to disable syntax checker and the error is gone.
Have anyone met similar problem?Can anyone give any suggestions?
Thanks!
The question seems to be a silly one! You just need to install "lintr" package in your R session first. The solution came from Jonathan H in the now dead Google+ Emacs Community (link removed)
install.packages("lintr")
Markdown preview command doesn't work.
I installed markdown-mode.el on emacs by using package-install.
Then I created test.md file as a trial. Syntax hi-lighting apparently works fine in the text.
When I used "C-c C-c p" command in order to show markdown preview, I got following error message in backtrace buffer. Even if I saved test.md file in current directory, it still said "No such file or directory". The file is located in "~/workspace/daily_log/test.md."
I tried "M-x markdown-preview" instead of shortcut key. But it doesn't work,too.
Do I make a mistake about usage of markdown-mode? Any help would be appreciated. Thanks in advance.
Error message in backtrace buffer
Debugger entered--Lisp error: (file-error "Searching for program" "No such file or directory" "bash.exe")
call-process-region(1 36 "bash.exe" "/tmp/emacsAxnXZ9" #<buffer *markdown-output*> nil "-c" "markdown")
shell-command-on-region(1 36 "markdown" "*markdown-output*")
markdown("*markdown-output*")
markdown-preview()
call-interactively(markdown-preview nil nil)
command-execute(markdown-preview)
my environment
OS: Ubuntu 14.10
emacs: 24.4.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.12.2)
markdown-mode: markdown-mode-20140914.1012/
If you inspect the backtrace you'll see that this has nothing to do with your Markdown file.
markdown-preview needs an external markdown command that can generate HTML. It looks like whatever Markdown processor you are using is trying to call bash.exe (not bash) when converting your file.
You might have installed some Windows-centric Markdown converter.
You might have customized markdown-command, directly or indirectly causing it to call bash.exe.
Since you are on Ubuntu, a simple apt-get install markdown should give you a decent Markdown that works with markdown-mode's markdown-preview function. After installing markdown at the system level, make sure that Emacs has markdown-command set to markdown (the default value).
When I try (run-racket) or (run-geiser) on my Windows 8.1 machine running GNU Emacs 24.3 and Racket v6.1 I get the following output:
Welcome to Racket v6.1.
default-load-handler: cannot open input file
path: f:/c/Users/James/AppData/Roaming/.emacs.d/el-get/geiser/scheme/racket/geiser/startup.rkt
system error: The system cannot find the path specified.; errno=3
>
Which is decidedly odd, but after browsing the backtrace I still don't have a good idea what's going on.
Indeed, since Racket starts up fine it seems to be some strangeness in the way paths are passed from Geiser to Racket. The only other time I see this kind of path strangeness is when MinGW bash is involved, and that /c/ makes me think that it probably is. In fact, that path would be perfectly valid if not for the leading f:.
I'm at a bit of a loss as to how to approach this problem, as I don't know how Geiser communicates with Racket (I just started trying to use it today), but I would really like to get it to work, as I'm quite invested in Emacs as my editor.
So my question is thus: What possible problem points should I investigate, given the above as clues?
After some digging through the Geiser source I found in geiser/elisp/geiser-load.el the line:
(setq geiser-scheme-dir "/c/Users/James/AppData/Roaming/.emacs.d/el-get/geiser/scheme")
Which was probably generated incorrectly by MinGW make.
I changed it to:
(setq geiser-scheme-dir "c:/Users/James/AppData/Roaming/.emacs.d/el-get/geiser/scheme")
After which everything works perfectly.
The problem was that Emacs' expand-file-name assumed that the /c/... path was a relative path due to the initial forward slash, and guessed that it should prepend the letter of the current drive to make it a proper Windows Emacs path.
I'm checking out a segfault in one of our apps. A short time after starting the app, the main gdb status bar changes to:
(Debugger:run [signal-received])
A (gdb) prompt appears but the contents of all other windows remain unchanged (empty). Typing anything at the prompt does nothing - gdb appears to be hanging. Running the same steps on the command line results in the expected output from gdb with a complete and correct backtrace.
This is my first time debugging with the -i=mi integration between emacs and gdb. I'm using emacs 24.2 and gdb 7.5.
Are there any suggestions on how I can debug this further?
Is it possible to reduce the level of integration? Would that allow me to determine which area is causing the problem?
A final point is that the initial loading of the app takes around 70s compared with around 3s from the command line.
Load time can be reduced by setting gdb-create-source-file-list to nil (use customize). See the documentation for what this does and why it substantially increases load times in some instances.
You can use M-x gud-gdb to use the old gud mode (i.e. without the mi interaction). Less fancy but more reliable.
It appears that gdb-ui from emacs 23 will still work in emacs 24:
Find a copy of gdb-ui (In my case gdb-ui.el.gz and gdb-ui.elc from a backup)
Place these into a directory (I have added ~/emacs-modes)
Then add the following to your .emacs:
(add-to-list 'load-path "~/emacs-modes")
(require 'gdb-ui)
Running gdb will now use the old --annotate=3 mode rather than -i=mi.
I'm using the latest nXhtml checked out from the repo, and using GNU Emacs version 24.0.91.1. When I open a PHP file it shows as un-syntax-highlighted text, and I get a compile error:
Error: Wrong type argument: number-or-marker-p, nil
and a message in the log:
File mode specification error: (cl-assertion-failed (functionp byte-compiled-fun))
I'm avoiding my .emacs and .emacs.d by running emacs with this command:
emacs -Q --eval '(load "/path/to/nxhtml/autostart")' /path/to/nxhtml/tests/in/heredoc.php
Even if you don't have a fix, how can I go about debugging this issue?
There seem to be a fair amount of such wrong-type-argument errors lately with the development version of Emacs (24). This might represent an Emacs bug. Or it might represent an nXhtml bug.
I suggest starting by notifying Lennart, the nXhtml author, trying to give him a clear recipe, starting from emacs -Q.
If that doesn't help, consider filing an Emacs bug: M-x report-emacs-bug.
To try to debug it a bit yourself, be sure to load only source files (e.g. for nXhtml), i.e., *.el, not *.elc, starting preferably with emacs -Q (no init file). Do M-x set-variable debug-on-error t to see where the error is raised. Then perhaps use M-x debug-on-entry FUNCTION, where FUNCTION is the function where the error seems to have been raised. Then step through the Emacs debugger, hitting d to step and c to skip through a step.
But again, I suggest starting with Lennart.
Try the newest version of Emacs.
I had the same problem (on Windows 7):
Error: Wrong type argument: number-or-marker-p, nil
at line 1471 of nxhtml-loaddefs.el.
Nxhtml seems fine on Emacs 24.1.50.1 (23 April 2012).
http://alpha.gnu.org/gnu/emacs/windows/?C=M;O=D