Explain the logic in README.md

[antoine-gallix]

I've had issues with this plugin sometimes not working, and I had to search in the code to see exactly what was intended. I'd find it useful to have the logic written down in the readme for a quick reference.

[nakulj]

When did it not work?

Also, I think the description belongs in a comment in the script itself.

[antoine-gallix]

When using a plugin, I either expect it to work magically without reading anything, or to have the logic explained in human language. Expecting all plugin users to understand fluently fish script, or even going to the code in the first place would exclude a good share of users when they have a problem.

In my case it didn't work because we have a repo that gather code for multiple services of our system, and the python service I work on, along with the virtual environment, are in a subdir of the repo, not at the root of it. I understood the problem by reading the code of the plugin. I first looked at the readme some month ago, found no info, gave up, and just got back to it last week.

[antoine-gallix]

I can also imagine something shorter like:

## Working logic
- the plugin function is activated at directory change
- environments are detected if they are named `env`, `.env`,`venv` or `.venv`
- the current directory is searched, or the root of the current git repo, if applicable

[nakulj]

Ah, I think I understand your issue. I saw your PR as well; but I think we can find a more general solution. What if we used a config file to map directories to virtual environments? This seems to be what a lot of IDEs and language servers do.
I'll try and implement something.

[antoine-gallix]

you mean a config file (.autovenv, .venv_map,...) at the root of the repo that would have something like

python_module_a:.venv
js_module_b:.jsvenv
...

?