Automatic setting via a cache didn't override a previous auto load from cache - #16
Automatic setting via a cache didn't override a previous auto load from cache#16georgeharker wants to merge 59 commits into
Conversation
|
Thanks for pointing out the 'change directory' issue. I need to consider it more because that is not part of my workflow. also, move lualine feature to another PR. |
|
Will do! Let me know if you need any more info. Basically I have a default venv in my home dir which gets picked up on startup of neovim. I will often fire up neovim in my home dir (or implicitly if using a gui) then cd to some project with a venv. Auto-set is great. But it only works if there wasn't already one set. |
|
I've further modified this PR to delay cache retrieval until after VimEnter occurs - otherwise plugins which intercept vim.notify won't be active and in general firing notifies during startup can cause instability for neovim. |
|
Any thoughts? |
| require("whichpy.config").setup_config(opts or {}) | ||
| require("whichpy.usercmd").create_user_cmd() | ||
| require("whichpy.lsp").create_autocmd() | ||
| require("whichpy.envs").retrieve_cache() |
There was a problem hiding this comment.
I think simply delete retrieve_cache() is the easiest way to address your problem.
btw, call retrieve_cache() at the end of setup(), is just to be avoid a rare case: plugin loaded after lsp_attach (not sure the case exists or not).
There was a problem hiding this comment.
You may be right, I will need to play with the case where I cd to one directory and open files then cd elsewhere and open another file with a different env.
I think that still presents an issue as it would auto-select an env which would be similar to one having been set on startup.
I think there's a difference between explicitly picking an env and auto-selecting one in terms of semantics of use
There was a problem hiding this comment.
cd to one directory and open files then cd elsewhere and open another file with a different env.
How do you cd? :cd, :tcd, :lcd or something else?
I think there's a difference between explicitly picking an env and auto-selecting one in terms of semantics of use
Agree.
But I probably wouldn't make that distinction. I don't think this is a good solution.
I found the DirChanged event today. Using the event should be easier to understand and maintain, i think.
There was a problem hiding this comment.
I tend to cd, sometime I do a lcd or tcd.
I don't think operating on DirChanged is a good idea - it's supposed to fire on invoking an LSP (file opened). I'll try with the implicit initial retrieve disabled, it's possible this will just work as the client will be different per project root.
There was a problem hiding this comment.
It does appear that simply removing the initial retrieve would be good enough for now.
|
I think I agree with you - I've revised the PR to just make setting the env on startup optional (off by default) |
|
I took a bit of time to work out what was different in my setup. I think simply being able to invoke a retrieve_cache later would be sufficient (I could for example bind this to a change directory auto command). There was still an issue whereby output from plugins should not occur until after vim enter. I added a command to set the env based on cwd which can be invoked separately. What do you think? |
…ons, and add tests
2 participants
I have a global env which is found on startup. If I then (without opening a python file yet) go and cd to a directory I've previously explicitly set the env in, it wouldn't change the env to that directory as one was already set.
I think it's different having explicitly set an env vs having one picked from the cache, so I modified things to track if the env was explicitly chosen and a config option to allow automatic override when the previous setting was implicit.
For extra, I included a lualine component which uses "nvim-tree/nvim-web-devicons".