use closest dir with .envrc instead of direct parent for caching about emacs-direnv

[purcell]

Yeah, it depends a bit on the environment direnv is passed. In envrc, I always run direnv in a default (non-direnv-produced) environment, so it will always re-calculate the new env, which can be costly (well, usually more than a few milliseconds). What happens with direnv.el is that you are mostly passing the direnv-augmented environment to direnv, and when that environment contains DIRENV_MTIME, DIRENV_WATCHES etc., direnv uses that to quickly yield a cached result where possible. I'll probably move to calling direnv more frequently, anbd relying on its caching, but to do that I'll have to change how envrc invokes DIRENV, and effectively pass it the last-known env for a given direnv.

[wbolster]

cc @purcell

[purcell]

Yeah, this makes sense to me: it would at least make the updates predictable.

[wbolster]

i did some experimentation here.

direnv itself avoids running envrc already even if directories change (instead of blindly running and producing an empty diff), so it seems useless to try to be smart about that inside emacs, since direnv itself is already smart enough, and running direnv itself takes just a few milliseconds in those cases, which is fine to do once per buffer-switch.

(furthermore, using locate-dominating-file adds i/o to the mix since it has to stat() for potential .envrc files up the directory tree, and when direnv is executed it would just do the same again.)