Starting from the base environment creates problems with the omnicomplete.

[ubaldot]

Changing sys.path as done before makes omnicomplete (<c-x><c-o>) to crash, in-spite everything seems to be ok.
Perhaps is a problem connected to Vim sys.path but it should be investigated.

Temporary solution is to avoid starting Vim from the base environment.

[Konfekt]

Is this plug-in, as its name suggests, more about activating or switching an environment?
Since an environment has to be activated before Vim is entered, I wonder what :CondaActivate achieves?
Is it?

The internal sys.path used by Vim is also set.

This seems from a user's point of view important for omni-completion using the libraries of the current environment.

Could the environment on entering Vim be auto-detected to adapt the (missing) Vim settings?

[ubaldot]

Is this plug-in, as its name suggests, more about activating or switching an environment?
Since an environment has to be activated before Vim is entered, I wonder what :CondaActivate achieves?
Is it?

The internal sys.path used by Vim is also set.

Yes, exactly. It change the runtime. When you conda activate you don't just change the internal Vim, sys.path but you also change the shell $PATH and a number of other environment variables.

Could the environment on entering Vim be auto-detected to adapt the (missing) Vim settings?

In reality the setting is not missing, it is set to a certain value.
I wanted to auto-detect the environment, but for some reason it does not work. But it is also true that when I wrote this plugin my Vim scripting skills were very lower compared to now.

What I have observed is that some plugins don't seem to like when the runtime is changed dynamically, (see e.g. yegappan/lsp#338).

Anyways, PR:S are welcome :)

[Konfekt]

Thank you very much!

In reality the setting is not missing, it is set to a certain value.

I hesitated writing (missing), but it was meant that all the shell environment variables, such as $PATH, should already have been taken care of by the conda activate command in the shell before starting Vim, which is required to make :CondaActivate work; so the question was rather ifsys.path is the only missing setting that :CondaActivate must handle since the shell command cannot?

I wanted to auto-detect the environment, but for some reason it does not work.

Could you just quickly tell which command you expected to show it, but didn't?

[ubaldot]

I hesitated writing (missing), but it was meant that all the shell environment variables, such as $PATH, should already have >been taken care of by the conda activate command in the shell before starting Vim, which is required to make :CondaActivate >work; so the question was rather ifsys.path is the only missing setting that :CondaActivate must handle since the shell >command cannot?

Eh, I actually don't remember. One should add some echom and check what/how things are changed.

Regarding the startup, I have seen that one could try to use a VimEnter auto-command and call SetEnvVariables() passing the current environment and prefix.

Anyway, I just look at the code and there is room for refactoring.

[ubaldot]

Btw, by looking at conda info --json one can see what is changed when a virtual environment is changed.

[Konfekt]

In this discussion I didn't grasp why the counterpart for conda needed to be inside the environment before. It seems that the (https://github.com/Coacher/vim-virtualenv/) plug-in solved a similar problem without that need. Maybe @Coacher could give a hint if this is really necessary.

[ubaldot]

Oh that is interesting! Thanks for pointing it out!

I think that conda is more complex than virtualenv, and perhaps there are some nuances that I failed to grasp.
Consider, for example, that When you install conda a bunch of things are also added to e.g. .bashrc.
If @Coacher has any solutions I am all ears!

This was one of my first plugins, and as said there is also room for refactoring other than improvements room. PRs that include that or any other improvements are welcome! :)