Display some indication that we're waiting for a result for long-running evaluations

[bbatsov]

We should display some spinning bar in the minibuffer while waiting for interactive evaluation results. Something similar might be useful for the REPL as well.

[Malabarba]

I think the mode line might be more appropriate. The mode line process is specifically designed for this kind of thing.
Technically that's the property of the major mode, but I don't think clojure-mode has any plans to use the mode-line-process. :-)

[bbatsov]

I suggested the use of the minibuffer, because this is what make-progress-indicator uses. Basically my idea is to start showing something if the evaluation takes more than some preconfigured duration (e.g. 1 second) and to make it disappear when we hear back from nREPL. Not sure if we can use something standard for the modeline (obviously, rolling out our own progress indicator is on the table as well).

Technically that's the property of the major mode, but I don't think clojure-mode has any plans to use the mode-line-process. :-)

You're quite right. :-)

[Malabarba]

Not sure if we can use something standard for the modeline (obviously, rolling out our own progress indicator is on the table as well).

Well, there's spinner.el. But then, I'm biased, :-) so don't take as a statement that the mode-line would be definitely better.

[bbatsov]

Your package looks cool. If you're willing to integrate it, using it, instead of the built-in is fine by me.

[zarkone]

I'd like to try myself at Elisp and this feature looks like a good start. I've opened cider-interaction.el and my plan is to advice-add the cider-interactive-eval. advice would launch :before and cancel :after cider-interactive-eval this charming spinner.el in minibuffer. I'm not sure about using advice-add: is it idiomatic for Elisp or is it suitable for Cider..? Waiting for your help, opinions and suggestions.

[expez]

@zarkone It's not common to use advice for code that you own and can modify. The advice functionality is mostly used when interacting with code you don't own which does almost what you want it to.

edit: Why is this so? Well, the argument is mostly from readability and comprehension. It's harder to read code which is located in two (or more when you have multiple advice) places. It's also a mental burden to construct the effective function, from multiple pieces in order to reason about the whole. You're also limiting the user's ability to write her own advice, because she now has to keep track of your advice too.

[zarkone]

@expez this makes sense, thanks. I've just opened Elisp info page, and red the same :)

[Malabarba]

You can just hack away at the cider-interactive-eval function itself, no need for advices.
The only thing is that evaluations are done asynchronously, so it's useless to run some code after the function. You have to look into the function that processes results.

[zarkone]

i've noticed that if i interrupt the evaluation with C-g, i see the spinner still running (tried to reproduce #1115 ). After few times C-g i'm getting error in process filter: Quit, evaluation interrupted and Emacs unfrozen, but spinner still spins. It is because i've pressed C-g, but not called cider-interrupt. Not sure how to handle this situation.. for example, call spinner-stop after each C-g is certainly a bad idea. Of course, I can stop the spinner with cider-interrupt after that, but it is not obvious for other users, i guess.

[Malabarba]

That's a good point.
Apparently, in that case, you're interrupting Emacs while it's still reading the message sent by the nREPL subprocess. That's the only explanation I can think of, because evaluations happen asynchronously (so they don't hang Emacs), and once the evaluation result has been received stopping the spinner is the first thing that cider does (I think). So the only explanation I can think of is that it hangs while reading the message (and that's where you interrupted it).

I'm really not sure how we can avoid that.

[zarkone]

Yes, I think you are right -- I tried to slurp a big file. slurp returns
the result immediately, AFAIK.
Artur Malabarba writes:

That's a good point.
Apparently, in that case, you're interrupting Emacs while it's still reading the message sent by the nREPL subprocess. That's the only explanation I can think of, because evaluations happen asynchronously (so they don't hang Emacs), and once the evaluation result has been received stopping the spinner is the first thing that cider does (I think). So the only explanation I can think of is that it hangs while reading the message (and that's where you interrupted it).

I'm really not sure how we can avoid that.

---

Reply to this email directly or view it on GitHub:
#1197 (comment)