Do what I mean when I send a request

[ljos]

This is a work in progress to get DWIM functionality into the request sending.

This is supposed to make it possible to use the command es-execute-request-dwim and emacs will Do The Right Thing™.

The priority is as follows: If there is a request header, emacs will call the query under the cursor with those parameters. If there is no request header, emacs will call the query with the variables stored in es-mode. If the command is prefixed with C-u (or any other prefix) all queries in the buffer is sent from top to bottom.

[dakrone]

Great! I will test this! Is it waiting for more work? (wondering since it says [WIP] in the title)

[ljos]

I haven't tested everything completely yet. I have also not been able to work on this continuously so I am not sure if I remember correctly how I got to every part of the implementation.

The part with multiple queries in the buffer is not tested at all. It would also be nice to do it in a different way as right now it creates a new buffer per query. I am thinking there should be a better way of doing that, but I might leave that for a later PR.

The reason for the [WIP] is that I need to become confident that the implementation is doing the right thing.

[ljos]

I think I have removed all the most grievous bugs. If you could test and see if it works with how you use it now, that would be great.

If you want to call multiple queries in the same buffer you just call C-u C-c C-c. C-u is the standard prefix command in emacs.

[dakrone]

@ljos It looks like C-c C-c is not working in the body of a request with parameters. In test2.es being inside the _search request attempts to contact :80 (missing URL?).

I also notice that none of the org-mode examples in all.org work with C-c C-c either.

[ljos]

It wasn't that C-c C-c didn't work in the body, it didn't work inside a string in the body. It had to do with how I "fixed" marking when we needed to think of more than 1 query inside the buffer. I think it should work better now.

I am not sure how to do the URLs correctly. Right now I just check if the URL starts with / or _, and if it does I add the es-default-base to the url. Else, if the string does not start with http:// I add that to the string. Otherwise I just return the string itself. I am thinking there should be a better way of doing that.

I think the only reason the org examples failed was because I replaced es-add-html with es--fix-url. Now it should work.

[dakrone]

Cool, this is working better, but still has a couple of issues:

1 - C-c C-c on parameter line or opening bracket fails to find response

Example, (<|> is the cursor location), in both:

GET /_cluster/health?pretty
<|>{}

and

<|>GET /_cluster/health?pretty
{}

Both find and execute the previous request, instead of executing the one under the point.

2 - The last example in all.org doesn't work, giving Symbol's function definition is void: es-find-params

[ljos]

1. Ah. I know why. I think I need some regression tests. Don't know how to implement it though.
2. I changed the name there. I will fix it.

[ljos]

I believe I fixed the two problems you discovered.

[dakrone]

Awesome, the first issue is fixed, I'm still seeing the last example in all.org not working, this time complaining Symbol's function definition is void: es-get-request-body

[ljos]

I am slowing getting there. I didn't have time to test the org-babel thing today.

[ljos]

Now it doesn't fail on missing symbols anymore. I haven't tested it on an elasticsearch endpoint because I noticed a bug that I think we should fix.

es-goto-next/previous-request will jump past queries with no request headers.

[dakrone]

es-goto-next/previous-request will jump past queries with no request headers.

Yea, when I originally wrote it it searched forwards/backwards for parameters. If we want to expand it so it can jump between requests regardless of header existence I think that would be neat.

[ljos]

Now forward/backward does not skip queries anymore.

[ljos]

I refactored the org-babel mode and it seems to still work as intended.

[ljos]

@dakrone Are we ready to merge this?

[dakrone]

@ljos just tested it, I think it's good and ready to merge! Please go ahead and merge it :)