Closed m-g-r closed 7 years ago
I think main problem here that cider-any-eval
is highly coupled with nrepl
. So backend can't have enough flexibility.
I suggest following solution:
eval-any.el
module which will be responsible for major mode and backend search. No direct nrepl
opperations calls.cider-any-eval-uruk-sync
is already there(cider-any-eval-uruk XQUERY CALLBACK &rest ARGS)
xquery
- actual query as a string
callback
- callback function of this signature
(callback RESULT &rest ARGS)
args
are passed as is into callback when result is ready. This way you can pass arbitrary arguments to this low level functions.
On top of this we will build isolated backend, which will manage nrepl itself.
Please let me know if you like suggested API and I will start its implementation. The important note here is that this change doesn't requre whole project redesign. It simply change some interfaces.
Regards, Artem.
Hello there.
I'm starting to implement this API in the separate branch. I think if you can try it for real, that will be more sophisticated than guess on good design. You can find it in the new-api
branch.
So far we have eval-any-xquery and eval-any-xquery-sync functions. Backend at the top of the file is an example how to use it.
Also I move your file name related manipulation into separate plugin under examples directory. Same way as we did with pprint.
Note this branch require changes to the xdbc module. I'll do it right after we agree if this API change is neccessary.
Regards, Artem.
Only some quick replies:
Yes, I understand that this issue might make a change in design necessary.
For now, I have no time to look at that code, but I hope to fit it in soon. But one quick note: The passing of arguments is supposed to allow to get rid of this filename business! The filename is supposed to be one of the arguments so that no special variable (that introduces a race condition and other problems) is necessary. It would be good to allow for hooks in the handler to allow for that. (Or some better means as hooks are not nice.)
The design proposal sounds reasonable, though I haven't spent too much time to think about it for now.
May I ask a heretical questions? Will there be another backend than the uruk one? Do you have any plans to add one?
Thanks you Max
Backend system was introduced after first step of our negotiation with @hanshuebner I think it is reasonable that many languages can be evaluated in cider as far as it has clojure bindings.
But backend system necessary for this possibility is far more complex that we need just for xquery and uruk right now.
I don't think it worth it.
The passing of arguments is supposed to allow to get rid of this filename business!
I understand this. I keep it for backward compatibility. I can rewrite this if you describe how do you suppose to specify exact filename for xquery result.
For example you can type it each time xquery mode executed. Or only if you pass C-u argument to any command?
Did you find preferred way to specify filename before XQuery execution?
In a use case, I want to cider-any-eval a string (that contains an xquery). Now I need to pass additionally information to this call that can later be used by the display handler.
One example is the filename (or URI) in case the xquery returns a document. (Currently, this is implemented via a hack, that is, cider-any-uruk-buffer-filename. But this way has problems, e.g., when the XQuery actually fails cider-any-uruk-buffer-filename will not be reset and actually used for the next successful XQuery. This is actually a bug.) But another example, could be the information that the result of the XQuery is a document listing. In this case, I might want to put the cursor on the line that contains the first document URI and maybe install a key handler to retrieve this file when the user hits the return key.
I have to admit that I should replace the display handler by a custom handler for this latter use case (and maybe already to the file-handling stuff). But the information passing has to happen somehow. I would propose an optional argument for additional meta-information that is just handled through to the display handler. Or do you have a better idea?