Bad UX of starting for the first time in a project (takes too long with no feedback)

[michalrus]

Especially if the project pins a specific Nixpkgs SHA1, which you don’t have locally.

Quick workaround: run intero-nix-shim ghci in a terminal, in the project’s root directory.

Idea: maybe we could reuse that buffer Intero+Stack is using for auto-installation, without changes to Intero.el, but I don’t know how.

[michalrus]

intero-call-process is synchronous, it blocks entire Emacs if a command it runs takes too long.

It’s not a big problem with official Stack, as all the commands return almost instantly. But when using intero-nix-shim as intero-stack-executable, its first ever run will potentially take a long time, having to resolve all dependencies.

I don’t know what to do with this w/o massive changes in intero.el.

Hmmmmm.

It would be good if we could unmask Nix’s output when resolving the deps (now it goes to /dev/null) and have it displayed somewhere in Emacs in case of an error. That could work now without many (any?) changes, requiring Nix to be called only for stack ghci. This might be the best option, but we’d need to fake (guess?) outputs of that other, initial commands… 😕

I’ll investigate.

[shlevy]

Couldn't intero-nix-shim itself just call out to ghc etc. directly, trusting that ghc in PATH is set properly for the packages? e.g. using nix-buffer or similar?

[michalrus]

Sure. :) But it’s calculating this PATH that takes so long (at least initially)!

And, unfortunately, this calculation is currently run synchronously. If we could fake outputs of initial calls to intero-stack-executable before stack ghci is run (this time asynchronously!), we could postpone using Nix (in any form) until we’re in an asynchronous context. :) And after we are (when intero.el runs stack ghci), we don’t care how long it takes. Emacs is not blocked.

[michalrus]

If we cannot fake them, the only option I see is changing intero.el itself… And this doesn’t feel like a small diff. :(

[shlevy]

Right, but my suggestion is that intero-nix-shim shouldn't be calculating this path at all, and we can use nix-buffer to a) asynrchronously do the nix-build, with caching (it already does) and b) enable intero once the PATH is set up (which, due to the caching, will be right away except for the very first time you ever open a file in that project)

[michalrus]

Ah, I get it now, sorry! :)

• So to get an OOTB experience for users, we’d need to create another Emacs package, that would require both nix-buffer and intero?

• And intero-nix-shim ghci wouldn’t work in a regular terminal, you’d have to run nix-shell --run "intero-nix-shim ghci" in the project’s directory… Hmm, that kind of makes sense!

[shlevy]

For the first bullet point yes, or maybe just a recommended configuration in ~/.emacs.

I'm not sure what intero-nix-shim ghci does exactly but I've used e.g. inferior-ghci with nix-buffer as well as set up a shell-mode shell with paths set up by nix-buffer (for a coq project)

[michalrus]

It just runs GHCi for the current project, similar to their stack ghci. =) I meant a terminal outside of Emacs, sorry for ambiguity! But that’s irrelevant, everyone would probably run nix-shell --run "cabal repl" anyway.