plz.el
plz.el copied to clipboard
alphapapa
Add option to return body as buffer instead of string with `:as 'response`
This could be useful for handling responses with very large bodies.
This sounds useful. Another possibility: in the response buffer, bind a plz-response with nil body as buffer-local variable.
This sounds useful. Another possibility: in the response buffer, bind a
plz-responsewith nil body as buffer-local variable.
I don't understand what you mean.
I meant that you could somehow provide a plz-response object when plz is called with :as 'buffer. For instance, by setting the plz-response to some to-be-defined buffer-local variable. Of course, in order not to defeat the purpose of avoiding the allocation of a big string, this plz-response should be created with a nil body value.
Sorry, I still don't get it. What is the problem you're trying to suggest a solution to?
The idea proposed here is that, when the user needs the result to be a plz-response object, facilitating access to headers and such, and the user also needs access to the body, it would be more efficient to provide access to the body as a buffer rather than a string, by setting the plz-response-body slot to the buffer rather than a string.
Exactly. And I'm saying you could alternatively set plz-response-body slot to nil and set the plz-response itself to a variable local to the buffer response. The advantage is that there is no API change in the plz function itself. The original proposal would require introducing :as 'request-with-body or something like that. My suggestion would allow writing (let ((headers (plz-response-headers plz-response)) ...), assuming you name the said buffer-local variable plz-response.
But both possibilities seem fine anyway.
On a related note, I noticed that the :then function is evaluated in the response buffer and not on the buffer which was current at the time plz is called. Is this intended?
I would say it's more natural to not have this kind of (temporary) side-effect. For one thing, the :as 'buffer option is currently as useful as :as 'ignore, since the response buffer is passed implicit anyway. Also, it's a bit convoluted if you want to remember what the original buffer was inside the :then function.
On a related note, I noticed that the
:thenfunction is evaluated in the response buffer and not on the buffer which was current at the timeplzis called. Is this intended?
I think it would be most accurate to say that the buffer in which the THEN function is called is undefined. It's up to the user to make sure its code selects the correct buffer when needed.
I would say it's more natural to not have this kind of (temporary) side-effect. For one thing, the
:as 'bufferoption is currently as useful as:as 'ignore, since the response buffer is passed implicit anyway. Also, it's a bit convoluted if you want to remember what the original buffer was inside the:thenfunction.
If the buffer matters (as it often does), the user needs to save a reference to it and pass it into the THEN function, either with the function as a closure or as an argument.
Even though it would seem convenient, I don't think it would be good to try to do that automatically, because, e.g. the buffer might not exist anymore when the THEN function is called. As well, it's often necessary to save and restore point and/or window point, and that necessarily falls to the user.
Ah yes, of course. I guess this is a good point to mention in the documentation.