1) PATH and exec-path
Emacs does set exec-path from the value of PATH on startup, but will not look at it again later. But if you run a command, it will inherit PATH, not exec-path, so subprocesses can find different commands than Emacs does.
As Francesco says, this can be especially confusing for shell-command, as that does not run a process directly, but ...
I'd suggest using pyvenv library, it provides a neat interface to selecting a virtual env among several alternatives updating interpreter and library paths. You will need to alter WORKON_HOME variable (it defaults to $HOME/.virtualenvs used by virtualenvwrapper).
(setenv "WORKON_HOME" "/Users/Pablo/anaconda/envs")
After that choose the ...
PATH vs exec-path
The PATH environment variable lists directories for programs to find executable files (when executing a non-absolute filename). The exec-path Emacs variable lists directories for Emacs to find executable files (again, when executing a non-absolute filename). The value of exec-path takes its value from the environment variable PATH when ...
Well, as @dshepherd mentioned, you are missing /usr/local/bin in PATH. git is working probably only because there is symlink in /bin. Try export PATH=$PATH:/usr/local/bin in emacs terminal.
You can also check this out: https://stackoverflow.com/questions/8606954/path-and-exec-path-set-but-emacs-does-not-find-executable
In the future, in case of similar ...
When emacs starts a new external process using primitive functions such as call-process or start-process, the executable is searched in exec-path (and not $PATH)
However, a function such as shell-command starts the shell as a subprocess and passes it the command you want to run. In order to execute this command, the shell will then try to find the ...
This is an OSX annoying environment issue, the $PATH appearing in Emacs is coming from /etc/paths file, which then gets appended with whatever I've set in the shell. I added /Users/g/Library/Haskell/bin to the top of the /etc/paths file and it then worked fine.
Going into shell and calling echo $PATH in Emacs shows now: /Users/g/Library/Haskell/bin:/usr/...
It does sound like this was caused by the user who originally built the binary for you. If they didn't do so in some sort of stripped down environment then this would happen.
You might want to report it to the maintainers of your binary package so that they can fix the problem with their build process.
If you provide information about what platform you are ...
Directory-local variables were actually designed for this use case as well. Read the docs, especially at the end, where it discusses dir-locals-set-directory-class. The idea here is that you can keep the directory-local settings somewhere other than in the .dir-locals.el file.
Another way to accomplish this same thing is to make settings directory-...
This question has been already answered by rekado (thanks!) (as a reply to another more general question about eshell):
You can configure TRAMP to respect the PATH variable on the remote
machine (for remote eshell sessions) by adding
'tramp-own-remote-path to the list 'tramp-remote-path:
(add-to-list 'tramp-remote-path 'tramp-own-remote-path)
If you start emacs from your GUI environment (gnome, kde, ...) your shell startup scripts will not be sourced into your environment. So the $PATH that you carefully set in your .zsh will not be loaded. GUI environments do not generally source these, though they may load your ~/.profile file.
You can try adding this to your .pam_environment:
I've just finished implementing such functionality in my json-mode, which can generate JSON paths in multiple formats, including JSON pointer (RFC 6901).
After installing, to get JSON pointer paths, you'll need to add following to your init file (or use customize-group):
(setq json-mode-path-format #'json-mode-format-path-json-pointer)
After that, you'll ...
The Windows build of Emacs provides a function for this, w32-short-file-name.
(w32-short-file-name "C:/path with space (and parens)/") ; => "c:/PATHWI~1/"`
w32-short-file-name is a built-in function in `C source code'.
Return the short file name version (8.3) of the full path of FILENAME.
If FILENAME does not exist, ...
exec_path is initialized from the EMACSPATH and PATH environment variables. Emacs also adds the directory containing the emacs binary to the end. This is done at startup by init_callproc_1 in callproc.c (http://git.savannah.gnu.org/cgit/emacs.git/tree/src/callproc.c#n1466)
The systemd.exec man page has a section about the environment variables it sets ...
One (imperfect) solution is to use find-function-library. Given a function, this returns a pair (ORIG-FUNCTION . LIBRARY). Quote from the documentation: ORIG-FUNCTION is the original name, after removing all advice and resolving aliases. LIBRARY is an absolute file name, a relative file name inside the C sources directory, or a name of an autoloaded ...
If some part of the PATH gets lost then you can add it in your ~/.emacs
;;; We add /path/to/something/extra by appending it to the path
(setenv "PATH" (concat (getenv "PATH") ":/path/to/something/extra"))
;;; /path/to/something/extra is now at the end of the PATH.
;;; or you can use:
;(setenv "PATH" (concat "/path/to/something/extra:" (getenv "PATH")))
Another way to accomplish this is to simply tell the shell that it's a login shell so that it sources all of the right files. I do this for bash by setting explicit-bash-args to ("--noediting" "--login"). It looks like the equivalent for zsh would be to set explicit-zsh-args to ("-l").
So in my .emacs:
(setq explicit-bash-args '("--noediting" "--login"))...
It looks like the relevant bookmark function is bookmark-get-filename. You could advise this to expand or otherwise transform the path.
For example, add some 'filter return' advice to call expand-file-name:
(advice-add 'bookmark-get-filename :filter-return 'expand-file-name)
To be able to share a bookmarks file between systems, you need some way ...
It is one question per customer / thread ...
As to the first question, the great thing about Emacs from https://emacsformacosx.com/ is that it is a self-contained installation. The executable is inside the packaged Emacs.app wherever you installed it.
If you placed the Emacs.app inside the root /Applications folder, then your path to the Emacs executable ...
Ok, solved this one. It turns out that there was an export PATH in my .bashrc (as well as .bash-profile). exec-path-from-shell doesn't like this, and only wants that export to happen in .bash-profile. This warning message gives a hint of the expectation. But I didn't realize that the package doesn't work if the condition isn't satisfied.
You should remove :defer f, because you don't want exec-path-from-shell to be defer loaded and you are going to use function from it when Emacs starts. Try something like the following
:if (memq window-system '(mac ns x))
(setq exec-path-from-shell-variables '("PATH" "GOPATH"))
(setq feeds-file (expand-file-name "notes.org" org-directory ))
is perfect for emacs internal usage. It gives "D:/my_data/notes.org" with forward-slashes.
The relevant section of the emacs manual is G.3 File Names on MS-Windows. It says:
MS-Windows and MS-DOS normally use a backslash, ‘\’, to separate name units within a file name, instead ...
require(epc) in the stack trace indicates that epc.el is not found in your Emacs load-path variable.
You'll probably want to do something like:
(add-to-list 'load-path "/path/to/directory")
for the directory where epc.el lives.
(or load-file-name buffer-file-name))))
load-file-name is set when the elisp file is loading (and requiring), buffer-file-name is set when user use M-x eval-buffer to load the file.
Notes that it can't detect directory changes, for ...
An answer to the point : turn off displaying any outline path in the echo area.
Encountered the same problem : that behaviour appeared after changing the distribution from org to org-plus-contrib (from orgmode.org repository).
The under-the-point-headline-print-in-echo-area behaviour seems to come from org-eldoc which is activated via a hook in org-mode-...
Turns out, I needed to delete the TeXLive distribution which I had installed manually using the TeXLive Windows installer and reinstall TeXLive with the Cygwin setup.exe. This will place everything in the correct places for emacs to be able to see them.
I had to change eshell-interpreter-alist to
And provide the following function to make it work
(defun eshell-run-ruby-command-from-path (args)
(eshell-named-command "ruby.exe" (list (eshell-search-path args))))