I'm copying the following Scheme code into a buffer file on emacs from a pdf:
(define (plural wd)
(if (equal? (last wd) ’y)
(word (bl wd) ’ies)
(word wd ’s)))
The initial formatting is as a long string, and I manually edit it to the format seen above. The file loads, but when I use the function I get the error:
*** Error:
unbound variable: |’y|
Current eval stack:
__________________
0 (equal? (last wd) |’y|)
1 (if (equal? (last wd) |’y|) (word (bl wd) |’ies|) (word wd |’s|))
When I manually type this code and load the file, however, the function runs no problem.
In what way is the pasting/editing of the code messing with the formatting of the code?
Is there a proper way to copy-paste code into a file? I tried formatting the code in a text editor before pasting into the buffer, but that didn't work either.
Thank you for your time and help.
It was already answered in the comments by Barmar, but this should enable you to complete your question, and help anybody else with the same problem in the future.
When you copy/pasted the code from the PDF, you did not copy a simple ASCII quote character '. Instead, you copied a "right single quotation mark" (unicode U+2019) ’. As this is not a reserved character in Scheme, it can be used as an identifier, and so what you expected to be the quoted symbol 'y was in fact the identifier ’y. The error was caused by there being no binding for the variable ’y.
A simple way of fixing this that does not required manually copying the code or fixing every quotation mark by hand is to find-and-replace ’ for ' (as long as you don't expect any ’ characters in your strings).
Related
I am running string-match using the pattern [ \[\]a-zA-Z0-9_:.,/-]+ to match a sample text Text [a,b]. Although the pattern works on regex101, when I run it on scheme it returns #f. Here is the regex101 link.
This is the function I am running
(string-match "[ \\[\\]a-zA-Z0-9_:.,/-]+" "Text [a,b]")
Why isn't it working on scheme but works eleswhere? Am I missing something?
After discussing the issue on the guile gnu mailing list, I found out that Guile's (ice-9 regex) library uses POSIX extended regular expressions. And this flavor of regular expression doesn't support escaping in character classes [..], hence that's why it wasn't matching the strings.
However, I used the following function as a workaround and it works:
(string-match "[][a-zA-Z]+" "Text[ab]")
I don't see anything wrong with your regular expression syntax as it is quoted correctly so I assume there must be a bug in Guile, or the regexp library it uses, where \] just isn't interpreted the correct way inside brackets. I found a workaround by using the octal code point values instead:
(string-match "[A-Za-z\\[\\0135]+" "Text [a,b]")
; ==> #("Text [a,b]" (0 . 4))
Your regular expression isn't very good. It matches any combination of those chars so "]/Te,3.xt[2" also matches. If you are expecting a string like "Something [something, something]" I would rather have made /[A-Z][a-z0-9]+ [[a-z0-9]+,[a-z0-9]+]/ instead. eg.
(define pattern "[A-Z][a-z0-9]+ \\[[a-z0-9]+,[a-z0-9]+\\]")
(string-match pattern "Test [q,w]") ; ==> #("Test [q,w]" (0 . 10))
(string-match pattern "Be100 [sub,45]") ; ==> #("Be100 [sub,45]" (0 . 14))
Editing a Bash script I want to assign a filename to a variable.
E.g. inputfile=foo.txt
With std. settings I can't complete the filename without first inserting a space after the '='.
Is there any solution to this?
First of all, comint-dynamic-complete has been obsolete since Emacs 24.1. The replacement function is completion-at-point.
Now, if you starting looking at what completion-at-point actually does in a shell script buffer, you'll eventually end up in comint anyway. In particular, the function comint--match-partial-filename looks promising for an explanation of the behavior you described.
If I read that correctly, the problem here is that "=" is considered a valid part of a filename, at least on POSIX-like systems (see variable comint-file-name-chars). So, the completion mechanism is trying to complete the filename "inputfile=/..." which it can obviously not find.
If you never use a "=" in your filenames (or you use it so rarely that the working completion outweighs other downsides), you may want to consider doing something like (setq comint-file-name-chars "[]~/A-Za-z0-9+#:_.$#%,{}-") in the shell script mode hook (if you are on a POSIX system; on Windows it would look slightly different).
Hope that helps.
You can use bash-completion assuming your not on windows. It just requires a slight modification to work in sh-mode since it uses a comint function to determine the current completion candidate.
I like this because, in addition to completing filenames there, it also will give you all the nice readline completion like command line switches, etc. Here is an example setup using company, but you could remove the company stuff, since all you really need is to add the modified completion-at-point function.
;; required packages: company bash-completion
(eval-when-compile
(require cl-lib))
;; locally redefine comint-line-beginning-position so bash-completion
;; can work in sh-mode
(defun sh-bash-completion ()
(cl-letf (((symbol-function 'comint-line-beginning-position)
#'(lambda ()
(save-excursion
(sh-beginning-of-command)
(point)))))
(let ((syntax (syntax-ppss)))
(and (not (or (nth 3 syntax)
(nth 4 syntax)))
(bash-completion-dynamic-complete)))))
;; put this in your sh-mode hook
(defun sh-completion-setup ()
;; add capf function
(add-hook 'completion-at-point-functions
'sh-bash-completion nil 'local)
(company-mode)
(make-local-variable 'company-backends)
;; use company completion-at-point
(delq 'company-capf company-backends)
(cl-pushnew 'company-capf company-backends)
(setq-local company-transformers
'(company-sort-by-backend-importance)))
(add-hook 'sh-mode-hook 'sh-completion-setup)
Emacs doesn't show breakpoints in text mode.
I tried integrating the suggestions here and here, but failed (I am not a lisp programmer).
I tried:
(require 'gdb-mi)
(setq default-text-properties '(foo 1111))
(defun set_breakpt_cmds ()
"set breakpoint and indicate on editor"
(interactive)
(gud-break)
(gdb-put-breakpoint-icon "false" (get-text-property 1 'foo)))
(global-set-key (kbd "<f12>") 'set_breakpt_cmds)
The resulting error is
Wrong number of arguments: (lambda (arg) "Set breakpoint at current line." (interactive "p") (if (not gud-running) (gud-call "dbstop \
at %l in %f" arg))), 0
Note: A similar issue is this (following this). However the solution there doesn't fit me because I would like to be able to call the fix from .emacs file. This way it is easier to duplicate my emacs configuration when I setup a new linux box.
Thanks
The error you get comes from the fact that gud-break expects an argument (which isn't used), so just use (gud-break 1).
The message reads as follow:
the error is of kind wrong number of arguments
when calling (lambda (arg) ...) (where we see that exactly one argument is expected)
and it was called with 0 arguments.
Im trying to use CLISP on Windows. So, when I start it in Command line I see next
*** - SYSTEM::DRIVER: Character #\u0414 cannot be represented in the character set CHARSET:cp437
Break 1 [3]>
How can I fix this?
This is an FAQ:
What do these error messages mean: “invalid byte #x94 in CHARSET:ASCII conversion” and “character #\u00B3 cannot be represented in the character set CHARSET:ASCII”?
This means that you are trying to read (“invalid byte”) or write (“character cannot be represented”) a non-ASCII character from (or to) a character stream which has ASCII :EXTERNAL-FORMAT. The default is described in -Edomain encoding.
This may also be caused by filesystem access. If you have files with names incompatible with your CUSTOM:*PATHNAME-ENCODING*, filesystem access (e.g., DIRECTORY) will SIGNAL this ERROR. You will need to set CUSTOM:*PATHNAME-ENCODING* or pass -Edomain encoding to CLISP. Using a “1:1” encoding, such as CHARSET:ISO-8859-1, should help you avoid this error.
Note that this error may be signaled by the “Print” part of the read-eval-print loop and not by the function you call. E.g., if file "foo" contains non-ASCII characters, you will see such an error when you type
(WITH-OPEN-FILE (s "foo"
:direction :input
:EXTERNAL-FORMAT CHARSET:ISO-8859-1)
(READ-LINE s))
If instead you type
(WITH-OPEN-FILE (s "foo"
:direction :input
:EXTERNAL-FORMAT CHARSET:ISO-8859-1)
(SETQ l (READ-LINE s))
NIL)
CLISP will just print NIL and signal the error when you type l.
cp437 seems to indicate a code page. Code page 437 is "US-ASCII" if I remember correctly, that is only 7 bits. It seems that you need to configure your "Command line" to display unicode.
I'm trying use mit-scheme in emacs but I can't get passed that problem...
The problem is I don't know how to add white spaces in a file path in .emacs file
So far I've tried
(setq scheme-program-name
"/Applications/MIT:GNU\ Scheme.app/Contents/Resources/mit-scheme")
(require 'xscheme)
and
(setq scheme-program-name
"/Applications/MIT:GNU Scheme.app/Contents/Resources/mit-scheme")
(require 'xscheme)
but the outputs I get is
Can't exec program: /Applications/MIT:GNUScheme.app/Contents/Resources/mit-scheme
Can't exec program: /Applications/MIT:GNU
because there is a white space missing in the path..
I think this is not possible using the existing functions, due to the way scheme gets called. The function run-scheme contains an explicit call to the function split-string-and-unquote on the scheme program name. As a consequence, the path to the scheme program will always be split at the first space. This means it is impossible to use a path with a space in it.
This is a bug that should be reported to the maintainers I think.