Update environment earlier

[wyuenho]

This PR should fix #17 and #28.

The problems are firstly, before-hack-local-variables-hook doesn't get run if the file has not file local variables, and secondly post-command-hook is run after all the major mode hooks. If any major mode hooks expects exec-path to be the most updated value, the current implementation does not work for this expectation. It also runs too frequently unnecessarily.

To update the environment as early as possible, this PR moves the decision to just before the major mode hooks are run but after the major mode has been set up, after a window buffer change and after a window is selected.

In addition, this PR resets the environment to the HOME dir's whenever the user selects a non-file and non-whitelisted window buffer so as to mitigate the perception problem that justified the entire existence of this package.

[wyuenho]

An alternative implementation could be hooking into buffer-list-update-hook, but this works equally well. @wbolster what do you think?

[wyuenho]

@wbolster WDYT?

[wbolster]

ah yes, i gave this a try earlier.

some of the behavioural changes actually annoyed me: i lost my direnv environment even though i didn't want to. examples are opening a new scratch buffer to jot down some notes or copy-paste stuff from elsewhere, switching to a flycheck error window, opening an emacs debugger (e.g. on error). sure, expanding direnv-non-file-modes with a ton of other things could prevent that, but it feels like a negated way of expressing the behaviour i want. i understand this is a preference, e.g. envrc.el uses the opposite approach, but perhaps there is a better way? a direnv-linger setting or something like that? 🤔

i don't remember any issue with the change to the hooks/events that trigger (potential) direnv updated.

[wyuenho]

examples are opening a new scratch buffer to jot down some notes or copy-paste stuff from elsewhere, switching to a flycheck error window

Why would you want a per directory environment when you are doing these things?

a direnv-linger setting

What does this do? Is this a boolean flag to keep the current behavior? If nil, the behavior of this PR kicks in?

i don't remember any issue with the change to the hooks/events that trigger (potential) direnv updated.

I'm not sure what you mean, does it mean this PR doesn't interfere with normal emacs ops?

[wyuenho]

I'm going to close this as I've switched to envrc as it makes no sense to change the entire Emacs process's environment late.