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.
Related
Trying to have access to functions from another file. Placed (provide (all-defined-out)) inside the other file. Now trying to actually refer to it using full path:
(require “C:\Users\functions.rkt”)
returns this error: #%require: bad require spec in: “C:Usersfunctions.rkt”
(require "C:\Users\functions.rkt")
returns this error: read-syntax: no hex digit following \U
There are two syntax errors in this snippet:
(require “C:\Users\functions.rkt”)
For starters, the double quote characters are incorrect. And you must escape the backslashes, and as Ryan points using file is mandatory. Try this:
(require (file "C:\\Users\\functions.rkt"))
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)
I've got to learn how-to-design-program for a while.But once I started to use my Emacs to learn htdp, I met some problem.
THE PROBLEM IS THAT:
I typed #lang racket , but it just show:
> stdin::7: read: #lang not enabled in the current context
context...:
/usr/share/racket/collects/racket/private/misc.rkt:87:7
> racket: undefined;
cannot reference undefined identifier
context...:
/usr/share/racket/collects/racket/private/misc.rkt:87:7
And I use 'require' to load path.
stdin::30: cannot open module file
module path: #<path:/Desktop/htdp/convert.rkt>
path: /Desktop/htdp/convert.rkt
system error: No such file or directory; errno=2
context...:
standard-module-name-resolver
/usr/share/racket/collects/racket/private/misc.rkt:87:7
Also it can not work.
Can you help me to solve it?
P.S my system is Fedora20.
When you're running a racket script from the console, you shouldn't need to define the language on the first line. This flag
racket -I <language>
can be used to specify a language when running from the command line. #lang racket should be the default, so just remove the line and run your script from the command line using the racket command.
from the link https://docs.racket-lang.org/guide/Module_Syntax.html#%28part._hash-lang%29
it says:
The #lang at the start of a module file begins a shorthand for a module form, much like ' is a shorthand for a quote form. Unlike ', the #lang shorthand does not work well in a REPL, in part because it must be terminated by an end-of-file, but also because the longhand expansion of #lang depends on the name of the enclosing file.
I've tried linum and nlinum. Both have dreadful performance on files with 100k+ lines.
$ for x in {1.100000}; do echo $x; done > 100k.txt
$ emacs -q 100k.txt
M-x load-library linum
M-x linum-mode
M-> ;; it's not too bad to go to end of file
M-< ;; now this completely locks up emacs
The same operation with editors like joe is instantaneous.
Is there any solution other than to turn off line numbers with big files (exactly the type of files that you want to navigate with line numbers - I have in mind locating error lines in concatenated Javascript files)?
Or just use a different editor?
I think you found a bug, and you may report (report-emacs-bug) it. As per Tyler comment, it may have been already solved.
Things that may help you in the meanwhile... line-number-mode, goto-line, narrow-to-region and this cheapo-number-my-lines-in-a-tmp-buffer trick:
(shell-command-on-region (point-min) (point-max)
(concat "grep -n ^ " buffer-file-name)
(get-buffer-create "*tmp-linum*") nil t)
As far as I know, both linum and its derivative nlinum number lines even if you don't see them. In the case of 100k+ lines, this can be slow if numbering an individual line takes more than a few tenths of a millisecond. For me, (Fedora 19, Emacs 24.3.1), there's no noticeable delay. Try line-num.el, which only numbers lines that are currently visible and see if it fixes the problem.
Add this to .emacs file.
(global-linum-mode 1)
Since Emacs 26 you should use [global-]display-line-numbers-mode instead.
For example:
(global-display-line-numbers-mode 1)
or:
(add-hook 'prog-mode-hook #'display-line-numbers-mode)
(Or toggle them manually via M-x.)
The line numbering for these is implemented as part of the redisplay in C code, and is therefore efficient and performs well even with extremely large buffers.
To customize this feature use:
M-x customize-group RET display-line-numbers
I already looked through other topics, but I still couldn't find a solution. I'm trying to install "nxhtml" plugin for Emacs in windows 7. I already setup my "HOME" environment variable as "C:\". So, my .emacs.d folder is there, and I put the nxhtml in there and added the following line to my "_emacs.d" file, as the readme says:
(load "C:\.emacs.d\nxhtml\autostart.el")
But it doesn't load.
I also tried putting:
(add-to-list 'load-path "C:\.emacs.d\nxhtml")
(load "autostart.el")
But to no avail... can anyone shed some light here? tnx.
A number of points here:
Firstly, _emacs.d is not a default file name for your init file, ie emacs will not load it automatically. Try ~/.emacs.d/init.el, or ~/.emacs instead.
Secondly, Windows 7 has a feature where it prevents programs from writing to certain system directories, but for backwards compatibility for the many old programs that do this, rather than causing them to fail, it silently redirects the write elsewhere, in an application specific directory. C:\ is one of those directories, so setting your HOME to point there is asking for trouble.
Thirdly, see the other response about backslash being an escape character in Lisp strings.
\ is special in the (double-quote) read syntax for strings, as certain characters take on a new meaning when prefixed by a backslash (e.g. \n is a newline, \t is a tab, and \" is a double-quote character). When the following character does not have any special meaning in conjunction with the backslash, that character is used verbatim, and the backslash is ignored.
"C:\.emacs.d\nxhtml\autostart.el" is actually the string:
C:.emacs.d
xhtml^Gutostart.el
To include a \ in the string you need to write \\
However, although it will understand the backslashes, Emacs is nowadays consistent across all platforms in allowing / as a directory separator1; so just do that instead.
1 and the obsolete directory-sep-char variable has been removed entirely.