Feature request: call function at point and prompt arguments

[mallt]

When writing a clojure function I often find it helpful to repeatedly call the function with the same parameters and get the result as an overlay in the buffer.
I use a simple function for this at the moment that applies the hard coded arguments I want to test to the function at point:

(defun call-clj-function-at-point () (interactive) (save-buffer) (cider-interactive-eval (concat "(apply " (cider-current-ns) "/" (second (split-string (cider-defun-at-point))) " [4 6])") nil (list (point) (point)) nil))

Applied to a simple sum function this gives the following result:

(defn sum [a b] (+ a b)) => 10

Instead of hard coding the arguments, I would like to be able to supply them the first time I call this function (f.ex. in the minibuffer). When I call the function again, I would like
the previous arguments to be applied by default, but get the option to supply different arguments to test other cases.

Does this sound like a feasible idea? Or are there already alternatives available to accomplish the same result?

Thanks!

[bbatsov]

I'm not 100% certain what exactly are you trying to achieve and what's your use-case for this in general. Some more examples would be useful.

[mallt]

Here's a screencast to clarify the request with a small example:

What I basically would like to do is:

• Call the function at point
• Supply the arguments in the minibuffer
• Print the result as an overlay

As an extra it would be nice if the previous arguments were presented as default, to make it possible to keep testing the changed function with the same input parameters.

(note: the example above is hardcoded, it doesn't derive the arg list automatically yet)

[bbatsov]

I understand now. Well, doing something like this is definitely feasible. The only issue is that we'd always have to assume the biggest arity when doing something like this.

[bbatsov]

Btw, another way to achieve more or less the same result would be to just populate the defun-at-point in the minibuffer eval. eldoc is visible even then, so you'd know the args (and you'd have the minibuffer history to recall old invocations).

[mallt]

Thank you for pointing me to cider-read-and-eval! I think that will be indeed the easiest way to make this work. I hope to come up with a PR for this soon.

[mallt]

@bbatsov I've added 2 functions to test the minibuffer eval:

• cider-read-and-eval-defun-at-point
• cider-repeat-last-clojure-eval

Here's a small screencast:

After some testing I think this perfectly fits my needs. Do you think this approach is interesting for a PR?

[bbatsov]

cider-read-and-eval-defun-at-point

This looks good to me.

cider-repeat-last-clojure-eval

Honestly I'm not quite sure what this is supposed to do. :-) I'm assuming the idea is to recall to last evaluation after you've changed the definition of something, right?

[mallt]

Yes indeed, it is just a shorthand for cider-read-and-eval and then evaluating the previous history item.

[bbatsov]

Yes indeed, it is just a shorthand for cider-read-and-eval and then evaluating the previous history item.

You don't really need cider-read-and-eval for this. You can just use cider-interactive-eval internally. Or if using cider-read-and-eval you can just pre-populate the minibuffer, so people can edit the arguments if necessary.

[mallt]

I currently have it set to:
(defun cider-repeat-last-clojure-eval () (interactive) (cider-interactive-eval (car cider-minibuffer-history) nil (cider-defun-at-point 'bounds)))

But I think it can be confusing when your point is located on another defun than the previous eval. Maybe it should just print the result in the minibuffer, not as an overlay.

[Malabarba]

Still, it's pretty similar to just doing C-c M-: and then hitting M-p or <up>. Maybe we don't need an extra command for that.

[bbatsov]

Still, it's pretty similar to just doing C-c M-: and then hitting M-p or . Maybe we don't need an extra command for that.

This is what I was about the say. If it takes some context from the source buffer, an extra command makes sense. Otherwise it seems like an overkill.

[mallt]

Yes you're right, I guess it's better suited for my local config instead. :)