xquery-mode / cider-any

Evaluate any buffer in cider – Replaced by Oook
0 stars 1 forks source link

repair hack, rewrite #14

Closed m-g-r closed 7 years ago

m-g-r commented 7 years ago

Have a look at my latest commit. This has to be rewritten! I allowed myself to commit it nevertheless as it is an additional function that is only used by my newest xdbc-selector and nothing else.

The commit message is: add a function cider-any-string->list that is basically like cider-any-string but returns a list of values.

This is seriously hackish and should be replaced as soon as possible!

See source code comments, especially: +;; hackish without lexical let, should be improved!

proofit404 commented 7 years ago

Currently I'm going to reproduce my MarkLogic environment (I have to give my working laptop where it was installed previously). As soon as I will be able to run MarkLogic server on my personal laptop I will start to work on this issue.

m-g-r commented 7 years ago

Hi

In general, it would be nice to be able to just collect the result (usually as a list of strings I guess), and not have it inserted in a buffer.

That is also true for Clojure functions that I want to access from Emacs. Right now, I have written a simple function cider-eval-from that is based on cider-read-and-eval from cider-interaction.el; see attached file. cider-eval-form.el.txt

It just evaluates some Clojure code and prints the result in the echo area of Emacs. This is good enough if just want to execute something (like REST calls) and see the results. But also for this I know need to retrieve the result to do something with it in Emacs Lisp. (Here, I want to retrieve the connection config for cider-any-uruk from Cloure.)

Could this be a second backend for cider-any? Cider-any-clojure maybe? :) I got it right that cider-any is meant to make it easy to evaluate just anything via cider, right?

So this is something that is not only necessary for Uruk and MarkLogic, but in general. So it could also be tested without any MarkLogic installation. ;)

What do you think about all this?

Cheers, Max

m-g-r commented 7 years ago

Update: If I want the return value from clojure in emacs-list I now cider-eval-form/value that uses nrepl-sync-request:eval instead of cider-interactive-eval.

Something like that for cider-any would be nice. cider-eval-form.el.txt

Update: Improved version: cider-eval-form.el.txt

m-g-r commented 7 years ago

For now, I've put this into xdbc-selector. See file https://github.com/xquery-mode/xdbc-selector/blob/master/cider-eval-form.el

proofit404 commented 7 years ago

I'm done with first part of this issue. cider-any-string->list is reimplemented as part of the #13 issue resolution. Currently it stays in its branch. You can look at it here

I think we will have this fix eventually in the master branch, but if you want it immediately, I'll cherry-pick it.

proofit404 commented 7 years ago

I rewrite cider-eval-form.el as we discussed earlier. Please see https://github.com/xquery-mode/xdbc-selector/pull/2

I keep this module with same name, since its used only in xdbc-selector package. If you think there is a better place for this tiny utility module, say me and I'll move it there.

m-g-r commented 7 years ago

Hi,

cool. Please, keep also here in mind my recent bugfix in commit https://github.com/xquery-mode/xdbc-selector/commit/67a93889530eeb6283265e644bdbfbda2af6d704 Does your code still check that a cider connection exists? (cider-current-connection) might just return nil.

Cheers, Max

m-g-r commented 7 years ago

I can confirm that this doesn't check for the cider-connection but just files with a non-helpful error, caused by trying to use a connection that doesn't exist.

proofit404 commented 7 years ago

Fixed.

m-g-r commented 7 years ago

Cool, works nicely (with the added cider-ensure-connected that you've added in another commit).

Why is cider-any-eval-uruk-sync in cider-any-uruk? Does it actually have to be specific to uruk? In other functions I also just call cider-any-eval and not something specially using the uruk backend of cider any.

proofit404 commented 7 years ago

The reason why I put cider-any-eval-uruk-sync into uruk module:

Answering your question, this function isn't specific to the cider-any-uruk, but it specific to the uruk clojure library.

I agree that code duplication and copy-pasted solutions are problems.

But in this branch there are problems with functionality implementation so for now I concentrate my attention on this rather code style.

m-g-r commented 7 years ago

Ok, I didn't think about your new error handling. Then it is ok, of course.

Doesn't the cider-any-eval then also to open /Modules/security.xqy in the error buffer compilation in the say way, so there should be something uruk specific to call instead of cider-any-eval?

Cheers, Max

proofit404 commented 7 years ago

Compilation buffer.

Yes, compilation buffer must open /Modules/security.xqy uri of course. But I don't know how... What xquery I should run to see this module content? I was able to do that with absolute file name on remote MarkLogic server. But I can't tell if this is an appropriate solution.

Project structure.

By intention cider-any-eval is content agnostic function. It can evaluate any form no matter if it is clojure or xquery or anithing else. It delegates this job to the backend.

In the new-api branch I move this line forward and remove nrepl from cider-any-eval. Also this function has new name eval-any in the new-api branch. Its has only one purpose now - to be a generic minor mode with common key bindings.

All xquery specifics details must be implemented in the eval-any-uruk.el module. Also I make this decision more explicit by moving this module into eval-any-xquery.

Hope this make sense.

m-g-r commented 7 years ago

Compilation buffer: see the other reply in https://github.com/xquery-mode/cider-any/issues/13#issuecomment-255762837

Project structure:

proofit404 commented 7 years ago

Maybe we can just merge eval-any and eval-any-xquery into something like xquery-repl?

Remove whole backend thing and just write one minor mode on top of -eval and -eval-sync function?

I'm not insist on any name, you can suggest what ever you like.

I think cider is an implementation detail in the case of this module. This functionality can be done on top of any MarkLogic client library, so user interface and key bindings remains the same.

Maybe we can call it marklogic.el, marklogic-mode, marklogic-eval and marklogic-eval-sync?

m-g-r commented 7 years ago

Let's think about it for a night. It does sounds simpler!

Bye Max

proofit404 commented 7 years ago

Did you find sophisticated name for new module?

m-g-r commented 7 years ago

Well, marklogic.el, marklogic-mode, marklogic-eval and marklogic-eval-sync is a nice naming schema. What I don't like is that it all contains MarkLogic, as this is not official MarkLogic software, and also it talks xquery and REST, so it could actually also implemented for eXistDB, the same way it could use a different foundation than Cider and Uruk as you've said before.

So it is an XML database interface or helper. But xmldb-mode sounds as inelegant and ugly as xdbc-selector. Thus, maybe a completely different, more original name.

What about Ape? Referring to the librarian of the unseen university in the Discworld novels of Terry Pratchett? He is also a helper for a database (and also not a monkey). This would give: ape.el, ape-mode, ape-selector, ape-eval, ape-eval-sync? What do you think about it? I like it because it is short.

Cheers, Max

m-g-r commented 7 years ago

Hi Artem,

OK, let's get rid of the backend system and just make the single cider-any-uruk backend standalone. And if you've nothing against it, I suggest that Ape naming schema. Also, I think, Ape Selector is mildly funny. :)

Cheers, Max

proofit404 commented 7 years ago

Hi Max,

I totally agree with Ape naming schema. But I think we need additional description in the README :) Like that one.

I'll start this refactoring today in the new-api branch. I leave other branches untouched for now. They will be moved to the new naming scheme before merge.

Regards, Artem.

m-g-r commented 7 years ago

Hi,

cool, yes. But of course we cannot directly quote. But we should write something. :) Hey, looking at the web for short descriptions of the Libarian I have an even better name: Oook. :) What about oook-eval, Oook selector, etc.? I llke it much better! Also, it might have less a negative connotation (as, for example, in "ape mode", http://www.urbandictionary.com/define.php?term=Ape%20Mode)

Ook or Oook is the sound that the Librarien makes, and a much more direct reference to Discworld than 'ape' as it is more specific to it. Just google 'ook' vs. 'ape'. See https://en.wikipedia.org/w/index.php?title=Ook_language_(Discworld) or http://www.lspace.org/books/toc/toc-orangutan.html

Oook -- is all the Librarian at the university of the Discworld ever utters. He is the sole staff member of the greatest database of knowledge, and as such offers a very versatile and helpful interface to it.

I'm looking forward for your work in the new-api branch!

Cheers, Max

proofit404 commented 7 years ago

I've done code transition to the oook name. Please see README describing installation instructions for pprint and associate to file plugins. I understand that asking for the filename each time isn't optimal work flow. But it will at least prove that new approach works.

Regards, Artem.

m-g-r commented 7 years ago

Hi Artem,

cool! Who do we proceed to do the change of the projects? Should we carve out the new-api branch and make this a new repository xquery-mode/Oook? I'd do the same to xdbc-selector (making a new branch that uses oook and make this a new repository oook-selector). Afterwards mark the old repositories as abondoned.

If we rename the project, the URLs of the repositories will also change. And also this would leave behind cider-any with the old backend system, should anyone want to base other work on it.

What do you think is the preferred way to make the change over of both projects?

Other things: What's asking for a filename each time?

Cheers Max

PS: This text was a suggestion for the readme if you like it:

Oook -- is all the Librarian at the university of the Discworld ever utters. He is the sole staff member of the greatest database of knowledge, and as such offers a very versatile and helpful interface to it.

proofit404 commented 7 years ago

Hi Max,

I move new-api branch in to new Oook repository. error-buffer branch also was ported to new repository and adapt oook naming scheme already. Future work on it will be done there.

I made some transition of xdbc-selector to the oook-selector under new repository. I tried my best, but I'm not completely sure that I've done all things right. Please check code base attentively, I'm afraid I may introduce bugs unintentionally.

Other things: What's asking for a filename each time?

For now when you enable oook-to-file-mode it will ask for the result buffer-file-name each time you type C-c C-k. I leave a TODO note for you in the oook-selector repository. It point to the old style variable binding. Feel free to change oook-eval-buffer-to-file function in any way to be compatible with oook-selector.

Also I've added Librarian description to the README :)

Are we done there? Or there are some points to do with code transition?

Regards, Artem.