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?
Related
Using Emacs with ido mode enabled on Windows, Emacs tries to save a history file .ido.last when exiting. The file is located in C:/.ido.last, but it fails with a permission denied message. This is strange since I actually have access to that folder. However:
Is there a command to change the directory where the .ido.last file gets saved?
Short answer: (setq ido-save-directory-list-file "/some/file/name").
Long answer:
I keep all the little files that remember Emacs's state in a single directory under the user-emacs-directory. I'm not sure what this is on Windows, but I think it's C:\Users\<username>\Application Data\.emacs.d\. On Unix, it's ~/.emacs.d/. The variable user-emacs-directory should be defined by Emacs, no need to set it.
(setq emacs-persistence-directory (concat user-emacs-directory "persistence/"))
(unless (file-exists-p emacs-persistence-directory)
(make-directory emacs-persistence-directory t))
(setq ido-save-directory-list-file (concat emacs-persistence-directory
"ido-last"))
You may want to look at the no-littering package, which sets better default locations for files like this.
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.
I often use ido for auto-completion and tramp to access remote server via ssh. My .emacs includes the following lines:
(require 'tramp)
(setq tramp-default-method "ssh")
(ido-mode 1)
(setq ido-enable-flex-matching t)
(setq ido-everywhere t)
I want to disable Ido completion, when i'm browsing contents of remote server. Note that variable ido-enable-tramp-completion has nothing to do with my problem. Consider line /root#site.com#1234:/var/www/file.txt. I need Ido not to deduct the part after the colon (remote file path), i don't care about the part before the colon. I use ssh, and Ido makes Emacs lag for a few seconds every time i run ido-find-file, and when ssh timeout is over, Tramp tries to reconnect, asks me for a password and so on. This behavior is undesirable.
Emacs version - 24.0.94.1
Edit (20.03.12): After contact with Ido author I tried to change the ido-file-name-all-completions-1 to the following:
(defun ido-file-name-all-completions-1 (dir)
(cond
((ido-nonreadable-directory-p dir) '())
;; do not check (ido-directory-too-big-p dir) here.
;; Caller must have done that if necessary.
((and ido-enable-tramp-completion
(or (fboundp 'tramp-completion-mode-p)
(require 'tramp nil t))
(string-match "\\`/[^/]+[:#]\\'" dir))
;; TRAMP RELATED CODE DELETED
nil)
(t
(file-name-all-completions "" dir))))
No success. I then changed regex to
"\\`/[^/]+[:#]"
and it worked - Ido was disabled, when minibuffer contained that match. However as Ido couldn't see files on a remote server, it started calling ido-make-merged-file-list to search for files in other directories every time i enter something. This made working with Ido on remote servers even more pain.
I also tried setting up variables ido-slow-ftp-hosts and ido-slow-ftp-host-regexps to /root#site.com#1234, didn't help.
If you enter C-x C-f again you temporally disable ido-find and fall back to the default find-file.
For more information C-h f ido-find-file RET
To do this every time ido found a colon, I guess you have to write your own function for that.
I am using the following tutorial:
http://www.pchristensen.com/blog/articles/installing-clisp-emacs-and-slime-on-windows-xp/
I have set-up all the directories and downloaded all the necessary files. However, on step 4. I am using the emacs command "eval-buffer". I type in my settings, ran "eval-buffer", received feedback (in the bottom bar), and assumed everything worked correctly. Then when I ran M-x "slime" I received the error:
Spawning child process: invalid argument
I assumed I had typed something incorrectly in my .emacs file so I re-edited it. However, now when I attempt to run M-x "eval-buffer" I receive no feedback and I don't believe my new code executes.
My file, by the way, is:
(setq inferior-lisp-program "C:/Documents and Settings/U9UW/Desktop/root/bin/clisp/full/lisp.exe -B C:/Documents and Settings/U9UW/Desktop/root/bin/clisp/full -M
C:/Documents and Settings/U9UW/Desktop/root/bin/clisp/full/lispinit.mem -ansi -q")
(add-to-list 'load-path "C:/Documents and Settings/U9UW/Desktop/root/bin/emacs/site-lisp/slime/")
(require 'slime)
(slime-setup)
eval-buffer actually was evaluating. To fix the problem "Spawning child process: invalid argument", one has to replace the first line with:
(setq inferior-lisp-program “clisp”)
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.