Asynchronous update support

[hpfr]

trafficstars

Hi, thanks for making this package! Sometimes the process generating the local environment can take a long time.

https://github.com/astoff/buffer-env/pull/5 introduced a spinner and a buffer capturing process output. I wonder if it makes sense to go further and make the update process asynchronous. I’m thinking along the lines of Magit, where e.g. a fetch operation doesn’t block you from interacting with Emacs. This enables viewing the process buffer to check output when buffer-env-update takes a long time.

[astoff]

What is a long time in your case? If it's a few seconds, I'd say one has to live with it; if it's more, then probably you'd have to explain your use case.

The problem is that potentially one needs the buffer environment already set up in order to initialize the minor modes correctly (personally, I need it for Eglot to find the right language server).

[hpfr]

It can be a minute or more with a Guix or Nix manifest after I bump a channel pin, depending on how much software needs to be downloaded or built.

Yeah, I’m not suggesting opening the buffer before the environment is set; I also rely on buffer-env for Eglot. I guess I’m not sure how this would work given that most commands opening a buffer are synchronous. Maybe it’s not feasible to defer from `hack-local-variables-hook'.

I thought `envrc.el' was asynchronous, but I just tried it again and it seems to behave basically the same way.

Maybe an option to call display-buffer' on the process buffer during buffer-env-update' would be an improvement for folks wanting to see more progress information?

[quotuva]

Maybe an option to call display-buffer' on the process buffer during buffer-env-update' would be an improvement for folks wanting to see more progress information?

Along with, perhaps, a query on whether to abort the operation and let the process continue? EDIT: Sorry, I guess that would need asynchrony. EDIT2: ...but not this:

defer from `hack-local-variables-hook'