I had this exact same problem but it had nothing to do with RVM on ( which I also have ) on my Ubuntu-16.10 machine. It was related to by custom prompt (PS1)
The issue was the prompt PS1.
This fix : https://stackoverflow.com/questions/6954479/emacs-tramp-doesnt-work
Essentially in your .bashrc
case "$TERM" in
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 ...
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 ...
It looks like you've run the exec-path-from-shell from a Tramp buffer, so when it runs the shell, it attempts to do its magic on the remote server and then set the environment variables in your local emacs instance. That's almost certainly not what you want, and it's not a case that exec-path-from-shell is designed for. It looks like it's Tramp or your Tramp ...
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"))
The C function set_initial_environment in callproc.c populates process-environment and initial-environment together. Subsequent calls to setenv are the usual way of modifying process-environment (but noting that it's very common to be doing that in only a temporary dynamic scope). Obviously it's just a list though, so other manipulations are also entirely ...
exec-path is where subprocesses find executable files. so your emacs should be able to find the executable. However, require is looking not for the executable, but for hindent.el (or the coresponding compiled file hindent.elc) which is the emacs lisp interface to hindent. You have to modify load-path for that (or put hindent.el in one of the directories that ...
Apparently the .profile file is only supposed to be read on login
Correct. Invariably there are other shell resource files which are read on non-login shell invocations, however.
If your shell is bash then you can use ~/.bashrc for this, and including something like the following in your ~/.profile is then fairly common if you want your non-login settings ...
I ran into this problem, and the issue wasn't PS1--it had something to do with iterm's shell integration. The theory in this iterm2 bug report is that the escape characters used by the shell integration are confusing emacs.
A recent (not yet released) commit to the code disables shell integration for dumb terminals.
Before I saw that fix, I just changed ...
For future searchers: I used this to solve the problem:
It is a small elisp module that mimics the behavior of the /usr/libexec/path_helper
utility available on MacOS.
I added these lines to my .emacs
;; set path correctly on MacOS, based on /etc/...
Load library Dired+ (`dired+.el).
Use this command:
;; Change ROOT definition if you want a different Windows drive as root.
;; (Windows does not have a single root.)
(defun foo (regexp)
"Append the accessible directories that match REGEXP to `exec-path'.
You are prompted for the REGEXP."
(interactive (list (read-regexp "Regexp: ")))