RPROMPT expansion and async design about alien-minimal HOT 9 CLOSED

commit 4efd94f should resolve the issue with pyenv shell 'version'

from alien-minimal.

Just pulled down this change, but it seems like the __import_env() method is having issues.

I put a set -x/set +x in this method and it seems to be getting weird input:

+__import_env:2> read -r line
+__import_env:2> echo $'\C-[[01;31m\C-[[KAM_\C-[[m\C-[[KENABLE_VI_PROMPT=1\n\C-[[01;31m\C-[[KAM_\C-[[m\C-[[KKEEP_PROMPT=1\n\C-[[01;31m\C-[[KAM_\C-[[m\C-[[KSEGMENT_UPDATE=0\n\C-[[01;31m\C-[[KAM_\C-[[m\C-[[KSHOW_FULL_DIR=1\n\C-[[01;31m\C-[[KAM_\C-[[m\C-[[KSHOW_PROCESS_TIME=2\n\C-[[01;31m\C-[[KAM_\C-[[m\C-[[KTHEME=terminal\n\C-[[01;31m\C-[[KAM_\C-[[m\C-[[KUSE_NERD_FONT=1'
+__import_env:3> eval $'export \C-[[01;31m\C-[[KAM_\C-[[m\C-[[KENABLE_VI_PROMPT=1'
(eval):1: bad pattern: ^[[01
...

You can see that the eval export is choking on ^[[01. I believe this is due to my grep containing colors by default. Adding a --color=never option to the grep command that initializes __AM_ENVS fixed the issue for me:

+__import_env:2> read -r line
+__import_env:2> echo $'AM_ENABLE_VI_PROMPT=1\nAM_KEEP_PROMPT=1\nAM_SEGMENT_UPDATE=0\nAM_SHOW_FULL_DIR=1\nAM_SHOW_PROCESS_TIME=2\nAM_THEME=terminal\nAM_USE_NERD_FONT=1'
+__import_env:3> eval 'export AM_ENABLE_VI_PROMPT=1'
+(eval):1> export AM_ENABLE_VI_PROMPT=1
...

from alien-minimal.

It seems to be working on my mac.

 am-demo pyenv shell 3.7.2                                  [ 2.7.16| 2.5.0| 9.10.1] 
 am-demo pyenv shell 2.7.15                                  [ 3.7.2| 2.5.0| 9.10.1] 
 am-demo rbenv shell system                                 [ 2.7.15| 2.5.0| 9.10.1] 
 am-demo nodenv shell 5.3.0                                 [ 2.7.15| 2.3.7| 9.10.1] 
 am-demo nodenv shell --unset                                [ 2.7.15| 2.3.7| 5.3.0] 
 am-demo pyenv shell --unset                                [ 2.7.15| 2.3.7| 9.10.1] 
 am-demo rbenv shell --unset                                [ 2.7.16| 2.3.7| 9.10.1] 
 am-demo                                                    [ 2.7.16| 2.5.0| 9.10.1] 

Can you share a little bit more about your environment?

Mine is:
Macbook Pro 2017 (15", core-i7, 16gb Ram)
Terminal: Iterm2

from alien-minimal.

lol now it's working... just pulled down latest again and not having any issues!!

from alien-minimal.

Glad to hear that :)

If you could share your thought about VI stuff I would be happy ......

from alien-minimal.

Thanks for reporting the issue.

Issue with pyenv shell 'version' occurs because of the usage of async job. When a (async) job starts it starts in a new shell and does not pass the ENV vars from current shell. As a result pyenv shell 'version' does not take effect in async jobs.
Hope fully I will come up with a work around soon.

AM_SEGMENT_UPDATE config has been removed a couple of days ago. It no longer has any effect.

AM_ENABLED_VI_PROMPT is actually an experimental feature. As I don't use VI mode myself, I haven't given much effort on it yet.

from alien-minimal.

Yea, I noticed AM_SEGMENT_UDPATE was removed. So glad to see this code is still being worked on! I switched from alien to alien minimal not long ago and have enjoyed every minute of it!! And good to know about the async shell spawning.

My hack for right now fixes the issue for versions but removes async from the RPROMPT. In theory, the vcs portion should work fine in a new shell, just not the versions stuff. I'll play around with my hack more and see if I can get everything else working async.

Lastly, I wanted to say that I believe I have a fix for the VI mode. Once I get this hack worked out so my versions are working properly but I still have async where it's nice to have it, I'll look into submitting a PR. VI mode seems to be broken due to early shell expansion 😛

Edit: Just wanted to point out that tag 1.3.4 works without hack/modification.
Edit2: Looks like 1.4.0 works but 1.4.1 doesn't?

from alien-minimal.

1.4.0 works because there was a bug in the use of async job. jobs were no actually running asynchronously.

from alien-minimal.

With the __import_env() issue resolved, I'd expect that I could test the pyenv shell 2.7.15 output the same way I was before.

I've added an echo "${PYENV_VERSION}" to am_async_r_prompt() and an echo -n "test ${PYENV_VERSION} test" to am_r_prompt_render().
(edit: this echo statement in am_r_prompt_render() does indeed come AFTER the __import_env "${2}" call)

I then opened a new shell, verified the prompt and debug output was what I expected (ie; PYENV_VERSION is not set), and then ran pyenv shell 2.7.15 (ie; PYENV_VERSION is set). Unfortunately, the next prompt and debug output is not what I'd expect:

 ~ pyenv shell 2.7.15                                                   test test[PY:2.7.10|RB:2.3.7|⬡ 10.16.3] G:min [4D] 227998f ⭑
2.7.15
 ~                                                                      test test[PY:2.7.10|RB:2.3.7|⬡ 10.16.3] G:min [4D] 227998f ⭑

Notice how before the pyenv command, PYENV_VERSION was not set and therefore we get an empty line followed by a prompt with test test.
Noice how just after the pyenv command, PYENV_VERSION is set and therefore we get the value of the variable followed by a newline and a prompt. This prompt shows test test instead of test 2.7.15 test.

Edit2: FWIW, when I have debug logging in __import_env I can see that the PYENV_VERSION is being handled... so not entirely sure what is going on here...

+__import_env:2> read -r line
+__import_env:3> eval 'export PYENV_VERSION=2.7.15'
+(eval):1> export PYENV_VERSION=2.7.15

from alien-minimal.