I encountered strange behaviour of expand-file-name function on windows during installation of last cedet using el-get. The issue is related to generation of autoloads.
The autoload.el on last emacs 24.1.50 contains the following function:
(defun autoload-generated-file ()
(expand-file-name generated-autoload-file
;; File-local settings of generated-autoload-file should
;; be interpreted relative to the file's location,
;; of course.
(if (not (local-variable-p 'generated-autoload-file))
(expand-file-name "lisp" source-directory))))
In my case generated-autoload-file is:
"/home/ngulyamov/.emacs.d/el-get/cedet/lisp/cedet/srecode/loaddefs.el"
as I have $HOME$ environment variable pointed to C:/home/ngulyamov. In this case above function returns:
"d:/home/ngulyamov/.emacs.d/el-get/cedet/lisp/cedet/srecode/loaddefs.el"
due to source-directory contains:
"d:/devel/emacs/emacs-bzr/trunk_jenkins/".
As you can see it changes drive letter from C: to D:.
At the same time on emacs 23.3 this function returns semi-correct value as source-directory contains value:
"c:/Users/Sean/Downloads/emacs-23.3/".
According to expand-file-name function description:
(expand-file-name NAME &optional DEFAULT-DIRECTORY)
Convert filename NAME to absolute, and canonicalize it.
Second arg DEFAULT-DIRECTORY is directory to start with if NAME is relative
(does not start with slash or tilde); if DEFAULT-DIRECTORY is nil or missing,
the current buffer's value of `default-directory' is used.
The paths on Windows never start from slash or tilde.
Now my questions:
1. Does expand-file-name function behaviour correct on Windows?
2. Why source-directory contains value of developers paths?
Could we consider expand-file-name as buggy on windows? Or it is just wrongly used in autoload.el?
Thank you in advance.
Finally I figured out the reason. The issue is coming from Makefile of cedet which uses $(abspath) functionality of make 3.8. The cygwin version of make in this case returns UNIX way of path, i.e. /home/ngulyamov/... which then replaces by source-directory root in autoload by d:/home/ngulyamov/.... The GnuWin32 version of make works correctly but by strange reason I have the following issue:
C:\home\ngulyamov\.emacs.d\el-get\cedet>\gnuwin32\bin\make all
Removing loaddefs.el files from subprojects.
Generating autoloads.
make[1]: Entering directory `C:/home/ngulyamov/.emacs.d/el-get/cedet/lisp/cedet'
> autoloads
Wrote C:/home/ngulyamov/.emacs.d/el-get/cedet/lisp/cedet/loaddefs.el
Loading vc-bzr...
Generating autoloads for C:/home/ngulyamov/.emacs.d/el-get/cedet/lisp/cedet/cedet-android.el...
Memory exhausted--use C-x s then exit and restart Emacs
make[1]: *** [autoloads] Error 127
So dirty fix is specifying source-directory in autoload.el itself like:
(setq-default source-directory "C:/home/ngulyamov/.emacs.d/")
Anyway, why source-directory is pointing to developer's computer path is remaining open.
Related
There's a huge literature on the topic, but, nevertheless, I cannot get this done.
My ultimate goal is to work with fstar on Microsoft Windows.
C-x C-f resolves ~ as C:/Users/myname which is in line with my HOME environment variable in the Environmental variables Windows section.
(expand-file-name user-emacs-directory), as described here yields, C:/Users/myname/.emacs.d/
In C:/Users/myname/.emacs.d/ I have placed .emacs.el and init.el with the suggested script:
(require 'package) (add-to-list 'package-archives '("melpa" .
"http://melpa.org/packages/") t) (package-initialize)
However M-x returns undefined, no matter if I start Emacs with or without the -q flag (see here). My "Messages" buffer is empty".
A couple of things you could try:
Check the value of the variable user-init-file (use C-h v). That should tell you if Emacs loads the file you want it to load. If you started Emacs with the -q option, the value of this variable should be nil.
The error M-x is undefined can be caused by rebinding the Escape key. (That's because pressing a key while holding down the "Meta" key is equivalent to first pressing Escape and then the key in question.) Is there something in the init file that might cause this to happen?
Try starting Emacs with -Q instead of -q. This makes Emacs skip "site-wide" init files. I can't really think of a reason why your system would have any of those, but it might be worth ruling this out.
You could edit your question and include your entire init file (surround it with ``` on a line by itself), so we could have a look.
I am using emacs 24.3.1 to write programs (in C and C++ mode).
After compiling the current buffer, I run below command: M-x gud-gdb. Emacs gives a prompt like below:
gdb --fullname prog
However, sometimes the "prog" name is not the same as the executable name compiled from current buffer.
e.g. I completed five programs prog1, prog2,... prog5, and is currently working on prog6. But M-x gud-gdb gives me gdb --fullname prog5. (I want prog6 instead.)
Is there a way to correct this? Specifically, "correct" means forcing gud-gdb to use current buffer's name (without suffix) as the prog name.
Thanks in advance.
I think emacs uses a heuristic (based on what executable file is more recent or something like that) to figure out the default program to offer.
If your preferences are very specific you could define and use this function:
(defun my-gud-gdb ()
(interactive)
(gud-gdb (concat "gdb --fullname "
(file-name-sans-extension (buffer-file-name (current-buffer))))))
This function will execute gdb on a file named like the file you are editing without extension.
gud-query-cmdline accepts filename as an optional argument, which isn't served yet.
Patch below should provide it.
Make sure, file-permissions are set to executable
--- gud.el Sun Mar 17 12:52:42 2013
+++ gud.el Tue Jun 3 10:06:11 2014
## -716,7 +716,7 ##
"Run gdb on program FILE in buffer *gud-FILE*.
The directory containing FILE becomes the initial working
directory and source-file directory for your debugger."
- (interactive (list (gud-query-cmdline 'gud-gdb)))
+ (interactive (list (gud-query-cmdline 'gud-gdb (and (file-executable-p (buffer-file-name))(buffer-file-name)))))
(when (and gud-comint-buffer
(buffer-name gud-comint-buffer)
In windows, I set the variable inferior-lisp-program to be (shell-quote-argument "D:/Program Files/ccl/wx86cl.exe").
But when I run inferior lisp with the command run-lisp, emacs responds:
Searching for program: no such file or directory, "D:/Program
It seemed that emacs treats "D:/Program Files/ccl/wx86cl.exe" as two arguments "D:/Program and Files/ccl/wx86cl.exe" separated by a space character.
How can I make emacs treat "D:/Program Files/ccl/wx86cl.exe" as a whole?
Try using the old "Progra~1" compatibility name for "Program Files". So,
(setq inferior-lisp-program "D:/Progra~1/ccl/wx86cl.exe")
I'm trying to add a remote directory to my ecb directory pane by modifying the ecb-source-path variable in my .emacs file under Emacs 24.2, ecb 2.40, OS X 10.8.2. The following works via tramp from within emacs:
/username#server.com:/home/username
/username#server:/home/username (have set up an alias server->server.com)
/server.com:/home/username (username is same as local user, so can be omitted)
/server:/home/username
I'm not sure whether I have the syntax wrong, but I've tried the following to add the path to ecb:
(setq ecb-source-path (quote("/username#server.com:/home/username"))) (**)
(setq ecb-source-path (quote("/server.com:/home/username")))
(setq ecb-source-path (quote("/scpc:username#server.com:/home/username")))
Which cause emacs to hang when issuing ecb-activate, with no error messages displayed in the message buffer
(setq ecb-source-path (quote("/username#server:/home/username")))
(setq ecb-source-path (quote("/server:/home/username")))
(setq ecb-source-path (quote("username#server.com:/home/username")))
Which result in message: Warning: Source-path <ENTERED PATH> is not accessible - ignored!
Has anyone done this and know the correct syntax for adding remote paths to ecb-source-path? According to the documentation, (**) should work. If the syntax is indeed correct, are there any tips for debugging what might be going on and causing emacs to freeze? Or is this an issue with ecb itself?
My .emacs contains
(setenv "PATH" (concat ".:/usr/texbin:/opt/local/bin" (getenv "PATH")))
(setq exec-path (append exec-path '(".:/usr/texbin:/opt/local/bin")))
(add-to-list 'load-path "/usr/local/share/emacs/site-lisp")
(require 'tex-site)
(load "auctex.el" nil t t)
(load "preview-latex.el" nil t t)
/usr/texbin is where latex/pdflatex/.. are located.
/opt/local/bin/ is where gs can be found.
And yet when I run preview-at-point, which apparently needs both latex and gs, I get
Preview-DviPS finished at Thu Dec 22 11:25:46
DviPS sentinel: Searching for program: No such file or directory, gs
which means that latex could be found all right, but not gs.
I am not sure whether setting exec-path is necessary, perhaps PATH is enough, but I've set it as a debugging measure.
Why can emacs not find gs even though the directory it's in is in both PATH and exec-path?
If you're setting $PATH inside your Emacs, you might well be on OS X. GUI applications are not started via your shell, so they see different environment variables.
Here's a trick which I use to ensure the $PATH inside Emacs is the same one I see if I fire up a terminal (but see "update" below):
(defun set-exec-path-from-shell-PATH ()
"Set up Emacs' `exec-path' and PATH environment variable to match that used by the user's shell.
This is particularly useful under Mac OSX, where GUI apps are not started from a shell."
(interactive)
(let ((path-from-shell (replace-regexp-in-string "[ \t\n]*$" "" (shell-command-to-string "$SHELL --login -i -c 'echo $PATH'"))))
(setenv "PATH" path-from-shell)
(setq exec-path (split-string path-from-shell path-separator))))
Then simply call the set-exec-path-from-shell-PATH function, perhaps from your Emacs init file. I keep that code on github, BTW.
Update: this code has now been improved and published as an elisp library called exec-path-from-shell; installable packages are available in MELPA.
Try replacing the second line with this:
(setq exec-path (append exec-path '("/usr/texbin" "/opt/local/bin")))
I hit a similar problem, but with a correct PATH, including trailing ´:´. It turned out the internal emacs shell program was missing, resulting in a ´Searching for program: No such file or directory´ message.
Fixed with
(setq shell-file-name "bash").
It appears you're missing a path separator : at the end of your path string.