Not sure what this means?
error(s) at startup! Spacemacs may not be able to operate properly.
--> deleting dockerfile-mode... [5/5]
Error in dotspacemacs/user-config: Wrong number of arguments: (lambda (mode unicode &optional ascii) "Dimi$
`dotspacemacs-mode-line-unicode-symbols'.
If ASCII si not provided then UNICODE is used instead." (list (quote add-to-list) (quote (quote spacemacs-$
cause I don't even have a user-config directory
Related
I'd like to be able to get my SBCL 1.4.5 (Linux x86_64)
Emacs 'inferior-lisp-process' to evaluate a S-Expression (sexp)
in some Emacs buffer that is not the 'slime' buffer - I have
latest quicklisp and slime-2.20 .
I thought this was exactly the same issue as in :
How to run Common Lisp code with Slime in Emacs Lisp
but it is not - my issue is that when I try to run 'slime-eval' or
any slime 'run in inferior-lisp-process' method ALL symbols seem to be
being looked up in ONLY in the SWANK-IO-PACKAGE namespace :
In my Emacs '*scratch*' buffer:
(slime-eval '(symbolp '+) "CL-USER")
Produces a backtrace error:
The function SWANK-IO-PACKAGE::SYMBOLP is undefined.
[Condition of type UNDEFINED-FUNCTION]
Restarts:
0: [CONTINUE] Retry calling SWANK-IO-PACKAGE::SYMBOLP.
1: [USE-VALUE] Call specified function.
2: [RETURN-VALUE] Return specified values.
3: [RETURN-NOTHING] Return zero values.
4: [*ABORT] Return to SLIME's top level.
5: [ABORT] abort thread (#<THREAD "worker" RUNNING {100262C8E3}>)
Backtrace:
0: ("undefined function" SWANK-IO-PACKAGE::+)
1: (SB-INT:SIMPLE-EVAL-IN-LEXENV \
(SWANK-IO-PACKAGE::SYMBOLP (QUOTE SWANK-IO-PACKAGE::+)) \
#<NULL-LEXENV>)
2: (EVAL (SWANK-IO-PACKAGE::SYMBOLP (QUOTE SWANK-IO-PACKAGE::+)))
It makes no difference whether I do :
(slime-eval '(symbolp :+) "CL-USER")
OR
(slime-eval '(symbolp '+))
I still get the same error because '+ and :+ are
always looked up only in the SWANK-IO-PACKAGE namespace.
I found this by simply trying to run, for my first test:
(slime-eval '(+ 2 2) "CL-USER")
which prints in the output buffer another backtrace
The function SWANK-IO-PACKAGE::+ is undefined.
[Condition of type UNDEFINED-FUNCTION]
I did try the code snippet from Question #22456086 :
(require 'slime)
(defun slrepl (str)
"Eval STR as Common Lisp code."
(unless (slime-current-connection)
(let ((wnd (current-window-configuration)))
(slime)
(while (not (and (slime-current-connection)
(get-buffer-window (slime-output-buffer))))
(sit-for 0.2))
(set-window-configuration wnd)))
(let (deactivate-mark)
(cadr (slime-eval `(swank:eval-and-grab-output ,str)))))
So doing:
(slrepl '(symbol-function '+))^X^E
Still results in :
The function SWANK-IO-PACKAGE::SYMBOL-FUNCTION is undefined.
[Condition of type UNDEFINED-FUNCTION]
Access to the default SB_INT namespace seems to be denied .
How to enable it for such cases ?
I'd like to be able to send forms to and read results from the same emacs inferior-lisp-process (sbcl) from any buffer, not just from the slime
'slime repl sbcl' buffer . Is there any way to do this?
Obviously, I can write an Emacs Lisp function to switch-to the
slime repl buffer and evaluate in that buffer.
Of course, all the above examples, eg. (eval '(symbolp '+)) ,
work fine in the slime-repl buffer. I guess there is no way
around switching-to the slime-repl buffer?
This might clarify:
In 'scratch' :
(slime-eval '(SB-INT:symbolp 'SB-INT:+) "CL-USER")^X^E
In slime output buffer:
Invalid protocol message:
The symbol "SYMBOLP" is not external in the SB-INT package.
Line: 1, Column: 26, File-Position: 26
Stream: #<SB-IMPL::STRING-INPUT-STREAM {1002A1CD63}>
(:emacs-rex (SB-INT:symbolp (quote SB-INT:+)) "CL-USER" t 78)
So, in the slime-repl buffer, I can do:
CL-USER> (PROGN (IN-PACKAGE "COMMON-LISP-USER") (+ 2 2))
4
CL-USER> (PROGN (IN-PACKAGE "SB-IMPL") (symbol-function '+))
#<FUNCTION +>
CL-USER> (PROGN (IN-PACKAGE "SB-IMPL") (symbol-function '+))
#<FUNCTION +>
SB-IMPL> (PROGN (IN-PACKAGE "SB-INT") (symbol-function '+))
#<FUNCTION +>
But if I try to run the same 'slime-eval' function in any
other buffer, eg. 'scratch' :
(slime-eval '(PROGN (COMMON-LISP-USER:IN-PACKAGE "COMMON-LISP-USER")
(symbol-function '+)) :COMMON-LISP-USER)
Invalid protocol message:
The symbol "IN-PACKAGE" is not external in the
COMMON-LISP-USER package.
Line: 1, Column: 46, File-Position: 46
I have tried ALL the likely PACKAGE names listed above in the
slime-eval with same results.
The same thing happens whether I use the 'slrepl' code snippet or just plain
slime-eval - no lisp standard syntax symbols are available. Do I need to
load the lisp syntax table or something ?
RE: can I switch to slime repl buffer and do it ? : NO ! :
(require 'slime)
(let ((slbuf (get-buffer "*slime-repl sbcl*")))
(if (eq nil slbuf)
(error "please start slime (M-x slime)")
(progn (set-buffer slbuf)(slime-eval '(+ 2 2) "COMMON-LISP-USER"))
)
)^X^E
Still results in :
The function SWANK-IO-PACKAGE::+ is undefined.
[Condition of type UNDEFINED-FUNCTION]
I am a rusty / returning LISP user and new to SBCL and slime .
I'd really like to integrate Emacs' great Editing and File management
& interacation facilitties with external CL XML & HTML generation & parsing
tools. But to start, I'd just like to get to the root of this problem...
Common Lisp symbols like + and symbolp are in the COMMON-LISP package. Short name CL. These symbols are usually not exported from package CL-USER. Thus symbolp can be referenced as cl:symbolp. These symbols are accessible in package CL-USER, but not exported from there. Thus you can also reference cl:symbolp as cl-user::symbolp -> note the two colons.
CALLING IN-PACKAGE in a form does not have an effect on the form itself, since the form is already read. Though it has an effect calling reader functions or functions like find-symbol.
CL-USER 5 > (defpackage "FOO" (:use))
#<The FOO package, 0/16 internal, 0/16 external>
CL-USER 6 > (progn (in-package "FOO")
(list 'bar (read-from-string "BAR")))
(COMMON-LISP-USER::BAR BAR) ; we now print from package "FOO"
Using SLIME-EVAL in Emacs Lisp
Best use it with a form, that reads the expression on the Common Lisp side and does not involve the Emacs Lisp reader/printer:
ELISP> (slime-eval '(cl:eval (cl:read-from-string "(+ 1 2)")) "CL-USER")
3 (#o3, #x3, ?\C-c)
ELISP> (slime-eval '(cl:eval (cl:read-from-string "'foo")) "CL-USER")
common-lisp-user::foo
But here you see that the result is brought back into Emacs Lisp via the Emacs Lisp reader - where packages don't exist.
Thus SLIME-EVAL makes very little sense as a simple remote execution interface...
This now works! Thanks !
(require 'slime)
(defun CL$ (str)
(let ((slbuf (get-buffer "*slime-repl sbcl*")))
(if (eq nil slbuf)
(error "Please start slime (M-x slime).")
(progn
(set-buffer slbuf)
(slime-eval str "CL")
)
)
)
)
(CL$ '(cl:+ 2 2))
=> 4
But I don't fully understand why I have to prepend all symbols with CL or
why this still does not work:
(slime-eval '(+ 2 2) "CL")
but this does:
(slime-eval '(cl:+ 2 2) "CL")
I thought the third parameter was meant to be made into the current package?
So why do I have to append 'cl' to every symbol .
But thanks for the help, and an otherwise great slime + sbcl .
I'm using Emacs 23 with xterm and am trying to bring my Linux system into the 21st century by switching from a POSIX locale to en_US.utf8. Problem: when I use the Alt key on the keyboard in this locale, xterm sends a two-character sequence. I'd like to fix emacs so that it sees, e.g., Alt-f as meta-f rather than the two-character sequence "\303\246". I think this might be a job for an input coding, but from the emacs documentation I have not figured out how to write one.
As an alternative I would be willing to add octal '\303' to a keymap so that emacs would treat it as a prefix character to introduce a meta escape. The way I would prefer to do this would be to bind '\303' to a function that then takes the next key and adjusts it as a meta key. But I can't quite figure out that one either.
Worst case I guess I write a loop that binds the meta keys for 'a' through 'z' or something equally horrid.
I've messed around with the set-terminal-coding-system, but the crux of the matter is that in a UTF-8 locale, xterm uses the Alt key to send non-ascii characters—the Alt key no longer behaves like meta. So setting the terminal coding system to UTF-8 merely enables me to enter Latin characters with diacritical marks. Not the behavior I hoped for.
I found a really horrid answer that involves guessing what xterm is doing around the meta key. Suggestions for improvement are welcome—I'd like to find code that could do this job cleanly.
(And FYI, I'm not the only one with this problem.)
Here's a truly horrible hack:
(unless (display-graphic-p)
(defun make-meta-key ()
(interactive)
(let ((e (read-event)))
(if (numberp e)
(let ((keys (vector (event-convert-list (list 'meta
(+ (event-basic-type e) 64))))))
(let ((result (key-binding keys)))
(command-execute result)))
(error "this can't happen"))))
(global-set-key [?\M-C] 'make-meta-key))
This seems to work around what xterm is doing.
ETA: revision to handle more meta sequences:
(unless (display-graphic-p)
;; deal with the Unicode sequences that xterm sends when Alt (meta) keys
;; are used. N.B. Works with Alt-letter, Alt-\, Alt-space, and Alt-Shift-:
(defun make-meta-key ()
(interactive)
(let ((e (read-event)))
;; (message "Got event %s; basic event is %s" e (event-basic-type e))
(if (numberp e)
(let* ((basic (event-basic-type e))
(shifted (+ basic 64))
(basecode (if (<= shifted 127) shifted basic))
(keys (vector (event-convert-list (list 'meta basecode))))
(command (key-binding keys)))
;; (message "Result is %s; commandp says %s" command (commandp command))
(command-execute command))
(error "this can't happen"))))
(global-set-key [?\M-C] 'make-meta-key)
(defun do-nothing () (interactive) nil)
(global-set-key [?\M-B] 'do-nothing))
I am using zenburn.el color-scheme in emacs 23. The function name that starts with "do-" gets highlighted, as given in the figure below --
How do I fix it? Any idea?
I do not observe this with Emacs 24.3 (the current development version).
The code which would have resulted in this highlighting is commented out in lisp-mode.el:
;; This is too general -- rms.
;; A user complained that he has functions whose names start with `do'
;; and that they get the wrong color.
;; ;; CL `with-' and `do-' constructs
;;("(\\(\\(do-\\|with-\\)\\(\\s_\\|\\w\\)*\\)" 1 font-lock-keyword-face)
So, what you need to do is:
(dolist (s (apropos-internal "lisp.*-font-lock" #'boundp))
(set s (cl-remove-if (lambda (l)
(let ((re (car l)))
(and (stringp re)
(string-match re "do-something"))))
(symbol-value s))))
or just edit lisp-mode.el, comment out the appropriate regexp, and rebuild.
This one's a little weird and I don't want to mess with it if someone else has already found the answer. On OS/X (observed in Snow Leopard and Lion) EMACS 23.3, when I attempt to dired my dropbox directory, I get the following error in ls-lisp-insert-directory
ls-lisp-insert-directory: Format specifier doesn't match argument type
it works fine on other directories through.
Any ideas?
There are some odd "files" in the "file-alist" returned for Dropbox directories by the "ls-lisp-insert-directory" function (in "ls-lisp.el") that don't have all the "normal" file attributes. This causes the error that you're encountering. You should report this to the GNU Emacs development list so that it can be fixed properly. In the meantime, you can work around this by cloning the "ls-lisp-insert-directory" function in your Emacs init file and by adding the following "or" code to the existing "setq" assignments for "fuid", "fgid", and "file-size" (the "or" ensures that the values are initialized to "" or 0 in the scenario where the value is nil - since this code is only trying to find the largest values, it's fine to do this) as follows:
;; Find the appropriate format for displaying uid, gid, and
;; file size, by finding the longest strings among all the
;; files we are about to display.
(dolist (elt file-alist)
(setq attr (cdr elt)
fuid (or (nth 2 attr) "")
uid-len (if (stringp fuid) (string-width fuid)
(length (format "%d" fuid)))
fgid (or (nth 3 attr) "")
gid-len (if (stringp fgid) (string-width fgid)
(length (format "%d" fgid)))
file-size (or (nth 7 attr) 0))
(if (> uid-len max-uid-len)
You will need to ensure that you
(require 'ls-lisp)
before the redefinition of the "ls-lisp-insert-directory" function.
I recently started using django-html-mumamo-mode which is part of nXhtml in emacs and everything seems to work except that when I start writing javascript code in an html page, I get the warning/error
Can't find library /usr/share/emacs/23.2/lisp/progmodes/js.el
I checked in that folder and all of the files have the .elc extension including js.elc, which is probably why emacs can't find it. Can I change something to make emacs just load the .elc file?
Edit: This continues to occur if I run M-x load-library js or M-x load-library js.elc
Edit2: I have confirmed that load-suffixes is set to ("el" "elc"), and that js.elc is in the progmodes folder, which is in load-path and that all users have read permissions for that file. I am using emacs version 23.2.1, and when I set debug-on-error to t I got a traceback, and it looks like the following part contains the error:
error("Can't find library %s" "/usr/share/emacs/23.2/lisp/progmodes/js.el")
find-library-name("/usr/share/emacs/23.2/lisp/progmodes/js.el")
find-function-search-for-symbol(js-indent-line nil "/usr/share/emacs/23.2/lisp/progmodes/js.elc")
(let* ((lib ...) (where ...) (buf ...) (pos ...)) (with-current-buffer buf (let ... ... ... ...)) (put fun (quote mumamo-evaled) t))
(if (get fun (quote mumamo-evaled)) nil (let* (... ... ... ...) (with-current-buffer buf ...) (put fun ... t)))
(unless (get fun (quote mumamo-evaled)) (let* (... ... ... ...) (with-current-buffer buf ...) (put fun ... t)))
(progn (unless (get fun ...) (let* ... ... ...)))
(if mumamo-stop-widen (progn (unless ... ...)))
(when mumamo-stop-widen (unless (get fun ...) (let* ... ... ...)))
Notably, the third line contains a reference to the correct file, but it ends up trying to load the wrong one. Has anyone seen this kind of thing before or have any idea how to fix it?
If you read the section in the Emacs manual on "How Programs Do Loading, the js.elc file should be loaded if normal library -loading commands (e.g. - "require", "autoload", "load-file", etc) are being used. Some things to do to debug this:
Does your userid have system security permissions to access the js.el file in that location?
If you type M-x emacs-version, what version of Emacs are you running?
The "load-library" command searches for lisp files in the "load-path". When you examine the contents of your load-path, is the specified directory in it?
Set the variable "debug-on-error" to "t" and re-attempt to write javascript code in an html page - when the error occurs, check the source line where the error occurs and, if it's not apparent from that what is causing the problem, post an update to your question with a few lines of the source where the error occurred as well as the stack trace that was produced by Emacs.
EDIT: Ok, now that you've added the stack trace, it's possible to see why the error is occurring. Here are the key lines from the "find-function-search-for-symbol" function (which is the function where the error is occurring in):
(when (string-match "\\.el\\(c\\)\\'" library)
(setq library (substring library 0 (match-beginning 1))))
;; Strip extension from .emacs.el to make sure symbol is searched in
;; .emacs too.
(when (string-match "\\.emacs\\(.el\\)" library)
(setq library (substring library 0 (match-beginning 1))))
(let* ((filename (find-library-name library))
In line#2, the function is setting the library name equal to the "*.elc" library name minus the "c" (e.g. it's converting it from "/usr/share/emacs/23.2/lisp/progmodes/js.elc" to "/usr/share/emacs/23.2/lisp/progmodes/js.el". Then, in line#7 of the above code, it's trying to find that source member (and failing as it doesn't exist). Looking further at the stack trace, the key line is:
(if (get fun (quote mumamo-evaled)) nil (let* (... ... ... ...) (with-current-buffer buf ...) (put fun ... t)))
which is called in the nXhtml "mumamo-funcall-evaled" function. The author of nXhtml obviously has not considered that the ".elc" file may exist but that the ".el" is not in the same directory. It appears that he used to distribute js.el with nXhtml but stopped doing so since it is now shipped with most recent Emacs distributions. So, in his environment, he probably has the ".el" files in the same directory as the ".elc" files and hasn't encountered this problem.So, you should probably do 2 things:
Notify the author of the nXhtml library so that he can fix the bug in his code.
Copy the necessary ".el" source files to "/usr/share/emacs/23.2/lisp/progmodes/" so that you don't get the error. Alternatively, you may choose to re-install js.el (and possibly some other modules) in another directory and put that directory ahead of "/usr/share/emacs/23.2/lisp/progmodes/" in your "load-path".
Doing #1 will get the problem fixed in the long-term while doing #2 should let you use nXhtml in the short-term.
Check your value of load-suffixes
C-h v load-suffixes. You probably want this to be something like (".elc" ".el"). If it is make sure that your mode hasn't set it to something weird, or bound it dynamically.