senny / rbenv.el

use rbenv to manage your Ruby versions within Emacs
89 stars 18 forks source link

rbenv doesn't work with eshell #15

Open lucaslward opened 7 years ago

lucaslward commented 7 years ago

So far, rbenv.el has been perfect to get rbenv working with emacs. Everything works except one thing: eshell. Ansi term works. Flycheck and rubocop work. inf-ruby and it's rails counterpart work correctly as well. So, it's very puzzling. Am I missing something? I just switched from RVM to rbenv. rvm.el used to have a problem where I would have to call rvm-use once per eshell session, and it would work thereafter. Doing the same with rbenv-use or use-global doesn't seem to have the same affect.

lucaslward commented 7 years ago

A little more data. My environment:

Emacs 25.1 running the latest Emacs Prelude

I ran the following code in my environment:

(message "%s" exec-path) (message "%s" eshell-path-env)

exec-path is what you expect, with the correct rbenv directories. However the eshell-path-env looks like the standard Mac shell settings.

I tried running the following:

(setq rbenv--initialized nil)

(rbenv--setup)

Which does fix the situation, but eshell is still a bit wonky.

lucaslward commented 7 years ago

I was able to resolve the issue by putting the rbenv.el file into the prelude personal/preload directory, and requiring it and loading the global mode at the end of the file. This appears to be an issue related to the order that prelude executes things. For now, my setup is working, I'll see if I can make a PR request into prelude to fix the issue there.

senny commented 7 years ago

@lucaslward thanks for the heads up! It's possible that eshell uses some variable upon initialization. In that case rbenv would need to run before you load eshell. Let me know how it goes.

arthurnn commented 7 years ago

I think i've noticed that before too. Not sure what eshell is using as ENV, might be it. Are you using emacsclient?

lucaslward commented 7 years ago

So, with the above fix, when I first load emacs, and load shell running ruby --version will give me the correct rbenv global that matches what's in my mode line. If, however, I cd into one of my project directories, running ruby --version will give me the Mac default ruby. Running the rbenv-use command will have no affect. Nor will running rbenv in eshell. It's worth noting that my .ruby-version file also matches global as well.

This is not a file loaded via emacs client.

lucaslward commented 7 years ago

Another strange wrinkle. If I start Emacs for the first time, and then immediately enter into eshell. As I said above, ruby --version will have the correct version. But when I CD into the project with my .ruby-version file, it will go back to the system ruby, as mentioned above.

However, if I start emacs, then open a file in my project, then open eshell, which will default the directory to the current directory of the file I was in when evoking the shell, then the ruby version will be correct.

This leads me to suspect something with how the shim is interacting with the path is the issue. I'm going to keep digging though. Any thoughts are appreciated.

hamzakc commented 3 years ago

Hi @lucaslward I know it has been a very, very long time :smile:

But I wanted to ask if you got to the bottom of the problem? I wanted to move over to e-shell, but the rbenv problem is preventing me from doing so.

Thanks.